Method to scan a forensic image of a computer system with multiple malicious code detection engines simultaneously from a master control point

ABSTRACT

A multi-engine malicious code scanning method for scanning data sets from a storage device is provided. The method includes, among other steps obtaining at least one data set from a storage device and generating a single forensic image of the data set and also applying a recover data application to the data set to generate a single recovered data set. A scanning is initiated of the single forensic image and the single recovered data set using the selected plurality of malware engines, where each of the malware engines, installed on the indepenent operating systems of the virtual operating system may be run concurrently on the single forensic image and the single recovered data set. A report is generated combining each of the malware engines reporting the results of the scans.

PRIORITY CLAIM

This application is a continuation of U.S. patent application Ser. No.14/072,367, filed on Nov. 5, 2013 which in turn claims the benefit ofpriority from U.S. Provisional Patent Application No. 61/796,263, filedon Nov. 6, 2012, the entirety of which are incorporated by reference.

BACKGROUND

1. Field of the Invention

The present invention relates to a method used to detect the presence ofmalicious code infections on a computer system. More particularly, thepresent invention is in the technical field of computer security thatincludes computer forensics. More particularly, the present inventionaddresses the limitations of existing malicious code scanningtechnology.

2. Description of the Related Art

When a computer device is infected by a malicious code infection theuser will often notice degradation of system performance as theinfection can create unwanted and time consuming system activity,excessive memory usage, and bandwidth consuming network traffic. Thesefactors can also cause instability problems leading to application orsystem-wide crashes. The user of an infected device may incorrectlyassume that poor performance is a result of software flaws or hardwareproblems, taking inappropriate remedial action, when the actual cause isa malicious code infection of which they are unaware.

Existing prior art of commercial computer security vendors use manydifferent forms of software to detect and attempt to remove instances ofmalicious code. This software can make use of various methods to detectmalicious code infections including scanning files on the computer aswell as allowing suspicious files to execute in a “sand-box” environmentto determine their scope and purpose. Integrity checking and heuristicanalysis are also other proven scanning techniques. Malicious codescanning generally involves examining files for a fingerprint or“signature” that is characteristic of an executable program known tocontain malicious code.

Detecting the presence of malicious code infections is challenging asthe authors of malicious code design their software code to be difficultto detect, often employing obfuscation techniques that deliberatelyhides the presence of malicious code infections on a computer system.For example, the application or program containing the malicious codemay not be displayed in reports designed to inform theuser/administrator of processes currently running on the compromisedcomputer.

When files on a computer system are scanned for malicious codeinfections several operations are performed in specific sequence.Preliminary actions are simple and quick verifications that can be usedto rule out the possibility that the file contains malicious code.Examples of operations performed early in the scanning process includecomparing checksums, file header information, number of file sectionsand other file properties that typically differ between clean andinfected files. By performing these functions in a prescribed sequencewhere the next step takes longer than the previous step, the entirescanning process becomes quicker as easier aspects of malicious codeidentification are tested first. In all cases, the last step in allcommercial and open source scanning solution is an attempt to remove themalicious code infections without causing additional harm to thecompromised computer or its data. The present invention does not supportthis last step as the forensic image being analyzed for malicious codeis a “read-only” file.

While existing commercial and open source malware vendors all serve thesame purpose, the identification and removal of malicious code, theirsuccess rates vary significantly. The digital signatures used toidentify instances of malicious code infections are closely guardedintellectual property. As a result, the effectiveness of any malwaredetection product is directly linked to the number of malicious codesignatures it is aware of, typically a function of its independentresearch. Digital signatures are not shared among competitors. As aresult, it is possible to scan a computer for malicious code usingvendor product “X” and find nothing indicating an infection. Incomparison, vendor “Y's” product would find the infection due to itsadvanced knowledge of emerging instances of malicious code and theirdigital signatures. Recent research has established that most commercialmalware products only identify, on average, 90% of known malicious codeinfections.

To be effective, commercial malware products need to take control of thefile system of the computer it is installed on. This control aspectenables it to prevent an infected file from infecting other files,spreading the malware to other files on the same computer, or in theworst case scenario, infecting other computer systems. But this need tobe in control of the file system comes at a cost. Using prior artarrangements, only one commercial malware product can be installed on acomputer system at a time. Trying to install multiple malware detectionproducts on a single computer system typically results in a deadlyembrace, where both products fight for absolute control of the filesystem. This deadly embrace results in a malfunctioning computer as eachmalware detection product sees the other as an adversary launching amalicious attack designed to take control of the file system. This “oneonly” installation limitation puts the user at another disadvantage inthat the malware detection product currently installed may have limitedknowledge of “new emerging viruses” and as a result is likely to reportthat a computer system is “clean,” when in fact it is infected with amalicious code infection.

OBJECTS AND SUMMARY

The present arrangement is directed to a method and system whereby aforensic image of a hard drive or the live acquisition of RAM/Flashmemory resulting in a forensic image of the memory from a singlecomputer system can be simultaneously scanned with multiple commercialand open source malicious code detection engines such that all detectionengines can be controlled from a master control point dashboard module.As noted above, prior to the present invention technical limitationsimposed by the current design of anti-virus software and malwarescanning engines prevented multiple instances of malicious codedetection software from simultaneously being installed on the samecomputer and run concurrently. This technical limitation is resolved bythe present invention such that an unlimited number of malicious codedetection engines (e.g. at least 32) can be brought to bearsimultaneously on the same hard drive forensic image or the liveacquisition of RAM/Flash memory so that both valid and deleted files andfragments can be scanned with multiple detection resources. The methodof the present invention drastically increases the effectiveness ofscanning for infections by factors as the scans are performed using thecombined knowledge of all malicious code detection vendors and theirglobal researchers.

In this application, the term “malicious code” refers to any softwarespecifically designed to infiltrate or damage a computer system withoutthe owner's informed consent.

Malicious code can include but is not limited to the following: viruses,worms, trojan horses, rootkits, adware, spyware and any other maliciousand unwanted software. Any computer device, such as a server, networkdevice, desktop, laptop, personal data assistant (PDA), tablet or smartphone, are a limited set of examples of what can be at risk from amalicious code infection. While “malicious code” and “anti-virus” tendto be used interchangeable in current security based publications,anti-virus is a subset of malicious code infections.

The term “forensic image” refers to a bit-by-bit, sector-by-sectorduplicate image of a digital storage. These storage devices can be aninternal hard drive or external storage device accessible either locallyor remotely or the live acquisition of RAM/Flash memory. There are manydifferent industry standards that describe the structure and content ofa forensic image. The most popular is the “E01—Encase Evidence File”forensic image structure created by Guidance Software™. The commonthread associated with all forensic images is the creation of an “exactduplicate” of all valid, deleted and unused storage space of a storagedevice in a manner that prevents the image from being modified, at anylevel, after creation. A forensic image therefore is a snapshot in timeof the state of a digital storage device such that its entire accessiblestorage capacity is duplicated in the form of a transportable file, orseries of related file segments, that can be reviewed and analyzed atlater points in time but not modified or altered in any way withoutinvalidating the entire forensic image. Forensic images are validatedthru the use of hash digests. When a forensic image is initially createdthe process can also be tasked with creating a single hash digestvalue/number that mathematically is a unique representation of theentire accessible contents of the storage device being duplicated.Future regenerations of this hash digest value will be identical to theoriginal value calculated as long as the content of the current forensicimage has not been altered or changed in any way down to the bit level.

The present invention is a method for analyzing both valid and deletedfiles contained within the duplicate forensic image of a computer systemfor the existence of all known forms of malicious code using multiplemalware engines simultaneously and whose scanning actions anddiscoveries made are coordinated by a software based master controlpoint dashboard.

An example of the benefit of the invention includes the following taskand results. In this scenario, the task would pivot on the need toexamine, as soon as possible, a potentially compromised computer systemto determine if it has been infected with any known malicious code.Because hackers routinely deleted files in an effort to cover theirtracks this task must include the scanning of both valid and deletedfiles. Examining live running computer systems for malicious codeinfections incurs certain risks, one of which is that the hacker hasshielded his/her malicious code from discovery within the runningoperating system environment. This invention eliminates this factor andmany other “live” scanning problems by first creating a bit-by-bitduplicate forensic image of the compromised computer so that all malwarescanning is performed against a static “read-only” forensic image. Theforensic image is then mounted as a physical/logical drive under one ofmany different operating systems so that it could be pre-processed byeither commercial or open source forensic analysis software.

The pre-processing of a forensic image includes recovery of deletedfiles as well as the extraction of e-mail and files from various formsof compressed or encrypted file archives. Once the pre-processing iscomplete the forensic image is simultaneous scanned by a least 32different malware engines. Each different malware scanning engine wouldbe hosted by an individual instance of a virtual operating system thatis hosted on a single physical computer/machine. These 32+ virtualmachines each have the ability to reach out and access the singleduplicate forensic image, scanning its read only content of valid andrecovered deleted files simultaneously. The parallel processing offeredby the virtual machines dramatically decreases, by factors, the timerequired by each malware engine to scan the duplicate forensic image ofthe suspected computer. Not only are time efficiencies increased but thesingle forensic image is scanned for every known instance of malware byat least 32 different vendors who specialize in keeping track of newmalicious code, code that one vendor may know about, but others do not.The gains realized by the simultaneous “many-to-one” approach to malwarescanning, along with the inclusion of deleted files in the malware scan,increases the possibility that known viruses, Trojans and malware arediscovered, where in the past they might have been missed due to thelimitations noted above. The scanning activity within the multiplevirtual machines is controlled and coordinated from a software basedmaster control point dashboard. This master control point is a functionof custom scripts and applications specifically created to furtherenhance the benefit of this many-to-one malware engine scanning process.

This present invention may be offered as both a hardware/softwareappliance and as an installable software application with dongleexecution control. The appliance may be a high-end server with multiple64 bit CPU processors, significant amounts of random access memory(RAM), high-bandwidth high-capacity physical hard drives along withsolid state drives, all coupled to high-speed RAID arrays supported bybattery backup devices. The hard drives will be provided in removabletrays to facilitate quick removal. For security purposes the appliancesare on figured as stand-alone systems with no network or Internetconnectivity initially enabled. The operating system installed mayadvantageously be an enterprise level operating system capable ofsupporting all of the hardware resources provided.

At a minimum, the software applications installed and enabled on theappliance include the operating system and software capable ofsupporting multiple instances of VMware or Hyper-V at the server andworkstation level. Each VMware or Hyper-V instance is configured with atleast the following software applications: (1) FTK Imager, (2) X-WaysForensics, (3) Custom scripts and applications unique to the processingenvironment, and (4) a SQLite database, along with one of the more of32+ different malware engines utilized by the present invention.

The present invention is a combination of existing processes that areapplied in a unique manner such that a new method for the scanning ofmalicious code on a computer system is established.

As set out below, it is an object of the above described invention toprovide:

Use of Forensic Images:

The malicious code scanning process in the present arrangement is notlaunched directly against the files on a computer system suspected ofbeing compromised, as current malware vendors do, but rather against aduplicate forensic image of the local storage device that was createdusing forensically sound duplication techniques (See e.g. FIG. 03, FIG.04, FIG. 05 & FIG. 07, described in more detail below). Launching amalicious code scanning process against a duplicate forensic image of acomputer system, given that duplicate forensic images can be designatedas “read-only” sources of data permits the exact same image to bescanned an unlimited number of times by different commercial andopen-source malware vendor solutions without changing the content of theforensic image being scanned. This is at least one distinguishingcharacteristic of the present invention.

Ability to Scan Deleted Files:

The existence of a duplicate forensic image of the computer systemsuspected of being compromised permits additional forensic analysis inthe form of deleted file recovery—a distinguishing characteristic of thepresent invention (See e.g. FIG. 08 & FIG. 15 described in more detailbelow). Current malware vendor solutions do not recover deleted filesfor scanning purposes. This limitation ignores the possibility thathackers, in compromising a computer system, have attempted to covertheir tracks by deleting incriminating files. Identifying these deletedfiles as part of a known hacker attack increase the odds that the propercorrective action steps can be taken sooner than later.

Custom Designed Console:

The coordination and execution of any new patentable method requiresthat a host of activities be configured, scheduled, coordinated,executed and monitored. To accomplish this goal the present inventionutilizes a custom designed user interface designated as the “MasterControl Point Dashboard” console (See e.g. FIG. 06 described in moredetail below). This console allows the user, typically one withadministrator privileges, to perform the following six major selectabletasks as detailed below from a single interface display console:

-   TARGET MEDIA: To mount forensic images or devices for scanning.    -   (See e.g. FIG. 7 described in more detail below)-   RECOVER DELETED: To configure and initiate deleted file recovery.    -   (See e.g. FIG. 8 described in more detail below)-   MALWARE ENGINE: To select and configure malware engines.    -   (See e.g. FIG. 9 described in more detail below)-   SCAN CONTROL: To configure/start/stop the scanning process.    -   (See e.g. FIG. 10 described in more detail below)-   MONITOR PROCESS: For real time feedback on malware discovered.    -   (See e.g. FIG. 11 described in more detail below)-   CREATE REPORTS: For analysis options and detailed results.    -   (See e.g. FIG. 12 described in more detail below)

The configuration and design of this user interface display is unique inthat the selectable functions presented embody the core elements of thepresent invention. In totality, no other malware vendor or open sourcesolution offers this combination of malware specific scanning andreporting options in a single user interface. As a result, this customdesigned user interface is a distinguishing characteristic of thepresent invention.

Simultaneous Scanning:

Another distinguishing characteristic of the present invention is itsability to scan a single duplicate forensic image with multiplecommercial and open source malware engines simultaneously (See e.g. FIG.09, FIG. 10, FIG. 13 & FIG. 16 described in more detail below). Currentvendor solutions typically only permit one malware scanning engine to beinstalled on a single computer system. Installing multiple malwareengines on the same computer system is actively discouraged by both theprior art commercial and open-source vendors due to technical conflicts.The present invention is a solution to this limitation as it usesmultiple virtual operating systems (e.g. VMware & Hyper-V, etc. . . . )to host multiple malware engines on a single physical computer system.Configuring each instance of a virtual environment to have a differentmalware engine running, such that each malware engine can reach out andaccess the same duplicate forensic image(s), establishes a unique methodthat is capable of performing simultaneous scanning at a level notavailable in today's marketplace.

Multiple Implementation Options:

A core driving force behind this present invention is the ability toscan a forensic image of a computer system suspected of being infectedwith multiple commercial and open source malware engines simultaneouslyfrom a designated “Master Control Point Dashboard” console interface(See e.g. FIG. 06 described in more detail below). This capability hasthe ability to manifest itself in numerous physical and logical formsthat modify the scanning and analysis process platform but maintain theoverall goal of the present invention, namely that of using multiplecommercial and open source malware engines to scan a computer systemsimultaneously for known infections. The authors of this presentinvention will present, as an example, three variations of the presentinvention (See e.g. FIG. 13 described in more detail below) that focuson a manual scanning approach (See e.g. FIG. 19 described in more detailbelow) and a network and Cloud based orientated scanning approach (Seee.g. FIG. 20 & FIG. 21 described in more detail below). These differentapproaches are not meant to be examples that describe the limitations ofthe present invention, but rather are examples for establishing that thecore driving force behind this present invention can be embodied asdifferent diverse processes that utilized the same method ofsimultaneous processing to accomplish identical goals.

Normalize Scanning Results:

Having multiple malware scanning engines producing differently formattedupdates and reports poses a significant logistics challenge. Forexample, malware vendors routinely use their own internally generatedidentifiers to name and describe malware infections discovered. It isnot uncommon for multiple malware vendors to have entirely differentnaming conventions for the same malicious code. The present inventioncopes with this situation by creating a normalization engine interfacespecifically created to take all the data generated by the differentscanning engines and normalize it into a single accessible format (Seee.g. FIG. 18 described in more detail below) such as the CommonVulnerabilities and Exposure (CVE) guidelines standard. This is anotherdistinguishing characteristic of the present invention as thenormalization of the data permits a wide range of consolidationfunctions to be implemented concerning files scanned, malicious codeidentified and reports generated.

Statistical Impact Projections:

The ability to gather data concerning a potential malicious codecompromise from multiple malware engines presents a unique opportunityto extrapolate findings previously unavailable to securityprofessionals. The present invention capitalizes on the availability ofthis data to create reports and projections on the impact of the currentcompromise on the organization's entire technological infrastructure(See e.g. FIG. 13 described in more detail below). The use of uniquescripts and programs authored specifically to detect the possibility ofzero-day exploits from the normalized data (as well as other relevantdata) makes the present invention unique in its focus as it is capableof discovering facts previously unknown. This is another distinguishingcharacteristic of the present invention.

Transportibility:

Organizations are tasked with protecting the privacy of their client'sdata under a variety of laws and regulations, as well as internalprivacy policies. These governing factors may prevent the organizationfrom allowing data from computer systems suspected of being compromisedfrom leaving their physical facility or control. To compensate for thisrestriction, the present invention can be embodied on a single physicalcomputer system that is configured to be shipped as two ATA racks to theclient's location via common carriers (See e.g. FIG. 01 & FIG. 02described in more detail below). This portability is anotherdistinguishing characteristic of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become evident to the reviewer as the included drawingsbecome better understood with respect to the details provided, wherein:

FIG. 01 is a block diagram titled “10U ATA Rated Shipping Case (1 of 2)”that illustrates the hierarchical structure of the hardware componentsrequired to embody the present invention. This diagram is of a fullypopulated 10U ATA rated shipping case that supports one-half of theoperational functions of this patent instance.

FIG. 02 is a block diagram titled “10U ATA Rated Shipping Case (2 of 2)”that illustrates the hierarchical structure of the hardware componentsrequired to embody the present invention. This diagram is of a partiallypopulated 10U ATA rated shipping case that supports one-half of theoperational functions of this patent instance.

FIG. 03 is a block diagram titled “Internal Hardware Write-BlockerEnvironment” that schematically illustrates an internal hardwarewrite-blocker environment in which commercial hardware components areused to create a duplicate forensic image of a hard drive that may befrom a computer system compromised by malicious code.

FIG. 04 is a block diagram titled “External Hardware Write-BlockerEnvironment” that schematically illustrates an external hardwarewrite-blocker environment in which commercial hardware components areused to create a duplicate forensic image of a hard drive that may befrom a computer system compromised by malicious code.

FIG. 05 is a block diagram titled “Internal Software Write-BlockerEnvironment” that schematically illustrates an internal softwarewrite-blocker environment in which commercial software components areused to create a duplicate forensic image of a hard drive that may befrom a computer system compromised by malicious code.

FIG. 06 is a simulated screen display interface to custom designedsoftware applications. It is titled “Master Control Point Dashboard:Multi-Engine Malware Scanning Options.” This figure is the home screenthat on one page presents an overview of all the operational functionsmade available by this present invention.

FIG. 07 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard:Target Media.”

FIG. 08 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard:Recover Deleted.”

FIG. 09 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard:Malware Engine.”

FIG. 10 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard: ScanControl.”

FIG. 11 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard:Monitor Process.”

FIG. 12 is a simulated screen display interface to custom designedsoftware application. It is titled “Master Control Point Dashboard:Create Reports.”

FIG. 13 is a simulated screen display interface to a custom designedsoftware application. It is titled “Master Control Point DashboardModule.”

FIG. 14 is an exemplary flow chart that details the conceptualcomponents required to scan one of more forensic images simultaneouslywith one or more malware detection engines.

FIG. 15 is a block diagram titled “Deleted Item Recovery Module” thatschematically illustrates the hardware/software environment required tosupport the recovery of deleted items from a duplicate forensic image.

FIG. 16 is a block diagram titled “Malware Scanning Engine PlatformModule” that schematically illustrates the hardware/software componentsrequired to interface with and control administrator initiated actionsdirected at multiple malware scanning engines for the specific purposeof simultaneously scanning a forensic image for malicious infectionsusing multiple commercial and open source malicious code detectionengines.

FIG. 17 is a functional block diagram titled “Malicious Code DiscoveryModule” that schematically illustrates the operational componentsrequired to support the use of multiple commercial and open sourcemalware scanning solutions to simultaneously scan forensic images formalicious code infections and report on the findings made. This figuredetails the preferred embodiment of this invention at the functionallevel and is the essence of the present invention at its core.

FIG. 18 is a functional block diagram titled “Normalization EngineProcess” that schematically illustrates the operational componentsdesigned to take dissimilar descriptions from different malware vendorsof the same malware infection and reduce it to a common referencedescription per the Common Vulnerabilities and Exposure (CVE)guidelines.

FIG. 19 is a block diagram titled “Example Of A Manual ProcessingEnvironment” that illustrates how the functions of the present inventioncould be reduced to an inefficient manual process that, despite itslimitations, could accomplish the primary goal of scanning a singleforensic image with multiple malware engines simultaneously.

FIG. 20 is a block diagram titled “Example Of A Network HostedManual/Automated Scanning Process” that details how the method that isembodied in the present invention can be configured to function in ainternal network environment.

FIG. 21 is a block diagram titled “Example Of A Cloud HostedManual/Automated Scanning Process” that details how the method that isembodied in the present invention can be configured to function in apublic or private cloud environment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention is a system, process and method that allowsduplicate bit-by-bit forensic images of a computer system's hard driveor the live acquisition of RAM/Flash memory to be scanned with multiplemalware engines simultaneously from a master control point dashboard.Moreover, the present invention is configured to be a portable solutionsuch that it can be shipped, via common carriers, to client locationswhose privacy policies prevent sensitive data from being taken off-site.More specifically, the present invention provides a process whereby thefiles and data on computer system storage devices, in the form offorensic images, can be scanned simultaneously from a virtualenvironment with multiple commercial or open source malware detectionapplications in a time period that is substantially less than if thescanning was performed sequentially. In addition, the present inventionhas the ability, via authored scripts and executable programs created,to collect relevant data and make statistical projections on the overallimpact of the malicious code infections discovered to date on theremainder of the client's technological infrastructure.

Although the present invention will be described in the context of aparticular operating system environment, specifically Microsoft'sWindows Server 2012 with Hyper-V, Microsoft's Windows 7 Ultimate orWindows 8.1 Pro and VMWare's virtual operating environment, thoseskilled in the relevant art and others will appreciate that the presentinvention is also applicable to other operating systems and virtualenvironments.

The described embodiments of the present invention should be construedas illustrative on its face and not examples of the current limits oftechnology with respect to the capabilities of the present invention.

FIG. 01 and FIG. 02 represent the front views of two componentstructures 100 that when connected together via wires and cables createa functional computer system that can be transported via common carriersto a client's corporate location anywhere in the world. Both of thesefigures represent commercially available ATA (Air Transport Association)rated cases specifically designed to hold computer system components ina rack environment. Both cases have 10U of rack space and each areequipped with four casters 112 so that they may be rolled, as required,to their destinations. For ease of illustration and because they are notrelevant to an understanding of the present invention, technical detailsof these commercially available ATA transportable cases are not includedin this application.

FIG. 01 is a block diagram of computer components 100, that whenattached to other computer components and properly configured arecapable of supporting certain features of the present invention. Thecomputer system components detailed in FIG. 1 are: keyboard, monitor andmouse 102; firewall and content filter 104; CPU chassis 106 with singleor multiple CPUs and appropriate amounts of RAM and external interfaces;appropriate amounts of hard drive “hot swap” trays and racks 108; andtwo AC powered battery backup devices 110 configured appropriately tohandle the power demands of all the components in this specifictransportable rack.

FIG. 02 is a block diagram of computer components 100, that whenattached to other computer components and properly configured arecapable of supporting certain features of the present invention. Thecomputer system components detailed in FIG. 2 are: a hard drive “hotswap” rack and tray interface 114; a RAID array 118 appropriatelyconfigured in size to host the forensic images created for scanning; aRAID array 118 appropriately configured in size to host the virtualoperating environment required by this invention; (two AC poweredbattery backup devices 110 configured appropriately to handle the powerdemands of all the components in this specific transportable rack, and aspare 1 U rack space 120 for future expansion of additional functions.

Both FIG. 01 and FIG. 02 attempt to convey the anticipated size in rackheight units (“U's”) of each computer system component required. Thepresent embodiment of this invention describes the rack space requiredas a total of 20 U's where a single U has a height of 1.75 inches and adepth of either 19 or 23 inches. To accommodate various shippingrestrictions with respect to size and weight, the total U's requiredhave been divided in half, resulting in the need for two transportableracks, each with 10U of rack space. Those familiar with theconfiguration of computer components in a rack and their respectiveplacement within that rack realize that any placement or positioning isan arbitrary assignment that can be changed later, as necessary, toaccommodate other factors such as heat and vibration. The specific typeof computer equipment as outlined in FIG. 01 and FIG. 02 describe one ofmany numerous configurations that can result in an operational computersystem capable of embodying feature of the present invention. FIGS. 01and 02 are meant to convey one of these options and as a result are notan example of the limits of this technology.

FIG. 3 is a block diagram 122 of the functional configuration requiredto use a commercial duplication device 128 with an internal hardwarewrite-blocker 126 to create a duplicate forensic image 130 of a computerstorage device 124. The hardware duplication device 128 described hereis a commercial product with a internal write-blocker 126. Thecombination of a commercial hardware duplication device 128 and abuilt-in write blocker 126 allows for the “static” duplication of anycomputer storage device. Static duplication infers that the storagedevice to be duplicated is removed from its host and attached to thecommercial device as the data source 124. The data found on the sourcedevice 124 is duplicated, sector-by-sector, to the destination device130 for the purpose of creating a forensic image. The write-blocker 126prevents any of the data on this source device from being modifiedduring the duplication process.

By default, forensic images based on the E01 format (EnCase ForensicImage File—file ext) are write-protected and include internal hashdigests. Any after-the-fact modifications to the content of an E01forensic image automatically invalidates the integrity of the image. Theembodiment of this present invention requires the availability offorensic images created from computer systems suspected of beingcompromised with malicious code. Where possible, these should be staticimages, so that malware scanning can be replicated on the exact samedata when required. For ease of illustration and because they are notrelevant to an understanding of the present invention, technical detailsconcerning these duplication devices are not included in thisapplication.

The purpose of providing FIG. 03 is to establish that the process andmethod of the present invention involves the scanning and analysis ofread-only forensic images that are exact duplicates of the storagedevices on the computer systems suspected of being compromised. The useof a forensic image permits multiple scanning passes, using differentmalware scanning engines, without ever changing the original content ofthe items scanned. FIG. 03 establishes the foundation by which theprimary input to the present invention is created.

FIG. 04 is a block diagram 122 of the functional configuration requiredto use a commercial external hardware write-blocker 132 to create aduplicate forensic image 130 of a computer storage device 124 using acomputer system 134. The overall description of this environment issimilar to FIG. 03 except that while this environment is also capable ofcreating duplicate forensic images, it does so using a typical computersystem and commercial write-blocker 132 as opposed to a dedicatedcommercial hardware duplication device 128.

FIG. 05 is a block diagram 122 of the functional configuration requiredto use a commercial or open source software write-blocking tool 136 tocreate a duplicate forensic image 130 of a computer storage device 124using a computer system 134. The overall description of this environmentis similar to FIG. 03 and FIG. 04 except that while this environment isalso capable of creating duplicate forensic images, it does so usingsoftware designed to act as a write-blocker 136 at the operating systemlevel, as opposed to a dedicated commercial hardware device.

While at least one of the forensic write-blocking environments describedin FIGS. 03 thru 05 is required to create a forensically sound duplicateimage, this hardware or software represents a function that “enables”the present invention, it does not embody it. The enabler functionserved by these three different forensic duplication environments isonly applicable “if” the malware scanning for malicious code needs to beperformed in a manner that is forensically reproducible. If that is notthe case, the duplicate image created can originate from an environmentwhere no write-blocker was required or used. Duplicate images createdwithout the use of some form of a write-blocker are typically describedas “live” acquisitions. The inputs to this present invention include astatic or live acquisition to be performed on a computer storage deviceso that a target, in the form of a forensic image, can be identified asan item to be scanned by the present invention's process. For ease ofillustration and because they are not relevant to an understanding ofthe present invention or the inputs required, specific technical detailsconcerning the differences between a static and live duplication processare not included in this application.

The present invention includes two primary inputs. As described in moredetail later in the application with respect to FIG. 13, the first is aforensic image 432 of the computer storage device to be scanned formalicious code infections, the second is a forensic image of the deleteditems recovered 434, 436 from free and slack space 13. While the presentinvention is designed to work with two primary inputs 432 436, thesedesign parameters to not prevent the present invention from only usingone of the primary inputs should a situation exist where one of theinputs is not available or there are valid reasons why scanning it wouldnot be productive.

Returing to the initial operation of the present arrangement, FIG. 06 isa block diagram that describes the overall functional aspects of the“Master Control Point Dashboard” console user interface. This consoleallows the user, typically one with administrator privileges, to performthe following six major selectable tasks from the top of the dashboardas detailed below from a single interface display console:

-   TARGET MEDIA: To mount forensic images or devices for scanning 208.    -   (See e.g. FIG. 7 described in more detail below)-   RECOVER DELETED: To configure and initiate deleted file recovery    210.    -   (See e.g. FIG. 8 described in more detail below)-   MALWARE ENGINE: To select and configure malware engines 212.    -   (See e.g. FIG. 9 described in more detail below)-   SCAN CONTROL: To configure/start/stop the scanning process 214.    -   (See e.g. FIG. 10 described in more detail below)-   MONITOR PROCESS: For real time feedback on malware discovered 216.    -   (See e.g. FIG. 11 described in more detail below)-   CREATE REPORTS: For analysis options and detailed results 218.    -   (See e.g. FIG. 12 described in more detail below)

Each of the above functional areas associated with FIG. 06 are focusedon a specific set of tasks that need to be individually managed so thatthe goal of present invention is realized within the scope of itsabilities. FIG. 06, on its face, is an exemplary home page for thepresent invention in that all options and functions that require useroversight or involvement are accessed from menu options displayed onthis custom designed console interface. This console is designed withthe purpose of connecting all other major and minor functions associatedwith the present invention together in a seamless manner so that the useof the present invention is accomplished with a minimum amount oftraining.

Included in FIG. 06 are three default menu options 204, 206 and 220 thatare available for selection on all sub-menus presented by this consoleinterface. These global menu options are: “Home” 204,” “Help” 206,” and“STATUS 220.” Clicking on “Home” button 204, as one would surmise, takesthe user to the “Home Page,” in this case the user interface displaytitled as FIG. 06. Clicking on the “HELP” button 206 provides the userwith a user's manual concerning the installation, operation andmaintenance of the present invention. Lastly, clicking on the “STATUS”bar 220 enables, in a toggle manner, the enabling or disabling ofconnectivity over local TCP/IP hardware components 100 and softwaredrivers 400 (i.e. from FIGS. 1, 2 and 13).

Lastly, with respect to the totality of FIG. 06, the user interface (asproposed in the block diagram as previously discussed above) has beendesigned as a common launch point for all other functions and processesrequired to scan a forensic image for malicious code infections usingmultiple malware engines simultaneously. A master dashboard such as thisprovides the ability to achieve the goals of the present invention in annon-haphazard or unformed manner. The operational parameters accessiblethrough these menu options may operate as the ‘glue” that holds thevarious aspects and functions of the present invention together as aviable entity.

With respect to the functional menu options detailed in FIG. 06, it isnoted that these menu options are the top layer of a custom designeduser accessible infrastructure that is supported by the operationalfoundation outlined in more detail below for example with respect toFIG. 13. The entire matrix of line item menu options detailed in FIGS.07 through 12 (61 in total 222 . . . 342) are linked to one or more ofthese operational concepts as outlined in FIG. 13. When a user selectsone of the exemplary sixty one (61) menu options 222 . . . 342 forexecution they are launching (in the background) scripts and programsthat utilize one or more of the conceptual entities to achieve specificgoals and tasks relevant to the usage of the present invention.

FIG. 07 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Target Media” 208 as shown inFIG. 06. Twelve options are presented in this sub-menu for the specificpurpose of creating a duplicate forensic image of a physical digitalstorage device, verifying its structural and content integrity via hashdigests and then mounting the forensic image created as a logical devicein a unique virtual environment. Those twelve sub-menu selections are:

-   -   [01] Acquire physical digital media as a duplicate forensic        image 222    -   [02] Select forensic image (E01, DD, etc.) for target mounting        224    -   [03] Verify integrity of forensic image using internal hash        digest 226    -   [04] Select partition(s) on storage device for target mounting        228    -   [05] Assign logical identifiers to mounted partition(s) (E:\,        F:\, etc.) 230    -   [06] Mount selected partition(s) as logical device(s) 232    -   [07] Verify the file structure integrity of all logical devices        234    -   [08] Perform forensic pre-processing functions on selected        partitions 236    -   [09] Trouble shoot unsuccessful mountings or integrity checks        238    -   [10] Select image/device partition(s) to include in scan 240    -   [11] Select image/device partition(s) to exclude in scan 242    -   [12] Unmount target media, partitions and/or logical devices 244

According to one arrangement, a function of the “Target Media” menuoptions in FIG. 07 and the associated twelve (12) menu options (lines[01] through [12] 222 . . . 244) exist for creating a forensically soundduplicate forensic image of the digital storage device suspected ofbeing infected with malicious code. The forensic image created isintended to be the primary input to the present invention and isreferenced throughout this application as the “Forensic Image” 432presented in the overview of the conceptual components that interactwith the “Master Control Point Dashboard” module 402 in FIG. 13, whichis discussed in detail starting with paragraph [1332]. All of the menuoptions, and their related functions, detailed in FIG. 07 are in thepublic domain and are not cited as being unique aspects for which thepresent invention can make a claim.

The twelve menu options identified above and in FIG. 07 are provided forthe user as a convenience and for the specific purpose of maintainingcontinuity with respect to the forensic pre and post processing requiredof data to be scanned for malicious content. All twelve optionsrepresent existing links to applications, scripts and programs availableat the time of this application. For example, with reference to thesemenu options:

-   -   “Acquire physical digital media as a duplicate forensic image”        222 see        http://marketing.accessdata.com/acton/attachment4390/f-000d/1/-/-/-/-/file.pdf        page 31 “Creating Forensic Images.” Note: While FTK Imager by        AccessData is a commercial application it is given away for free        by AccessData to the general public.    -   “Verify integrity of forensic image using internal hash digest”        226 see http://en.wikipedia.org/wiki/Md5deep which is a program        in the public domain capable of generating and verifying hash        digest values of raw forensic images.    -   “Mount selected partition(s) as logical device(s)” 232 see        http://marketing.accessdata.com/acton/attachment/4390/f-000d/1/-/-/-/-/file.pdf        page 22 “Image Mounting.” Note: While FTK Imager by AccessData        is a commercial application it is given away for free by        AccessData to the general public.

Because the software that enables these menu options is in the publicdomain they are not described in any additional detail since they arewell known and understood by one with ordinary skill in the art.

FIG. 08 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Recovered Deleted” 210 as shownin FIG. 06.

-   -   [13] Select mounted partition(s) to recover deleted items (DI)        from 246    -   [14] Select BLANK physical storage device to use as DI        repository 248    -   [15] Initialize/format storage device to be used as DI        repository 250    -   [16] Verify file structure integrity of DI repository 252    -   [17] Select type of forensic image to create from recovered        items 254    -   [18] Specify destination location of forensic image being        created 256    -   [19] Specify file name of forensic image being created 258    -   [20] Start deleted file recovery process 260    -   [21] Suspend deleted item recovery process 262    -   [22] Abort deleted item recovery process 264    -   [23] See results of deleted item recovery process 266

According to one arrangement, a function of the “Recover Deleted” menuoptions in FIG. 08 includes the eleven menu options (lines [13] through[23] 246 . . . 266) which are for assisting the user in the process ofscanning for and recovering deleted items from the forensic image 432created thru the use of the menu options in FIG. 07. The interaction ofthe forensic image 432 is presented in the overview of the conceptualcomponents that interact with the “Master Control Point Dashboard”module 402 in FIG. 13, which is discussed in detail starting withparagraph [1332]. Note that the “Recover Deleted” 210 process isdependent upon the existence of the forensic image 432 as an examinationsource, without it there can be no effort at recovering deleted files.

The eleven menu options identified above and in FIG. 08 are provided forthe user as a convenience and for the specific purpose of maintainingcontinuity with respect to the forensic pre and post processing requiredof data to be scanned for malicious content. All eleven optionsrepresent existing links to applications, scripts and programs availableat the time of this writing. For example, with reference to these menuoptions:

-   -   “[13] Select mounted partition(s) to recover deleted items (DI)        from” 246 see http://www.techpathways.com ProDiscover® Basic        Edition.    -   “[19] Specify file name of forensic image being created” 258 see        http://marketing.accessdata.com/acton/attachment/4390/f-000d/1/-/-/-/-/files.pdf        page 31 “Creating Forensic Images.” Note: While FTK Imager by        AccessData is a commercial application it is given away for free        by AccessData to the general public.    -   “[23] See results of deleted item recovery process” 266 see        http://www.techpathways.com ProDiscover Basic Edition.        Because the software that enables these menu options is in the        public domain they are not described in any additional detail        since they are well known and understood by one of ordinary        skill in the art.

FIG. 09 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Malware Engine” 212 as shown inFIG. 06.

-   -   [24] Select malware engine applications & signatures for        updating 268    -   [25] Select malware engine(s) to be used in scanning process 270    -   [26] Configure operational aspects of malware engine(s) selected        272    -   [27] Save/load operational configuration created for future use        274    -   [28] Select the partition(s) from the mounted images to be        scanned 276    -   [29] Initialize malware scanning engine(s) 278    -   [30] Register new malware scanning engine(s) 280    -   [31] Unregister current malware scanning engine(s) 282    -   [32] Purge malware engines of all previous reports & findings        284    -   [33] Adjust configuration to compensate for unexpected anomalies        286

According to one arrangement, a function of the “Malware Engine” menuoptions in FIG. 09 (lines [24] through [33] 268 . . . 286) are forallowing the user to select and then configure one or more malwarescanning engines to run against the previously created forensic imagecontaining valid files 432 and the forensic image containing deleteditems 436. Both of these forensic images 432, 436 are presented in theoverview of the conceptual components that interact with the “MasterControl Point Dashboard” module 402 in FIG. 13, which is discussed indetail starting with paragraph [1332]. Note that the forensic image ofvalid files 432 was created using the menu options in FIG. 07, while theforensic image of recovered deleted items 436 was created using the menuoptions in FIG. 08. All of the menu options detailed in FIG. 09 areunique with respect to the claims of the present invention.

The ten menu options identified above and in FIG. 09 are custom designedscripts and applications that are unique to the present invention. Thefunction of each of these ten menu options is explained in detail below:

-   Menu Line: [24] Select malware engine applications & signatures for    updating 268

Purpose: Selecting the menu option at line [24] 268 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select one or more malware scanning engines for updating.Note that each malware scanning engine 712 . . . 714 is hosted by adifferent and independent virtual operating system 704 in a virtualsupport environment 702 as described in FIG. 16. The updating functioncan be as minimalistic as refreshing virus signatures to upgrading theentire malware application with a newly released version. This codesegment is a sub-component of the larger “Master Control Point DashboardModule” 402 application which hosts all of the custom designed menufunctions presented in FIG. 06. The code segment for this menu lineoption 268 is unique in that it is designed to have the ability tocommunicate with every malware engine at the command line (CL) interfacelevel, or if necessary, directly with the graphical user interface (GUI)426 . . . 430 of the respective malware engines 712, 714.

Details on how this task can be accomplished, given that each malwareengine will be different, will be stored in the “Database Module” 410 asa specific table of data. When this menu option is selected and the useridentifies which malware engine(s) need to be updated, the code segmentassociated with this menu option will query the respective “DatabaseModule” 410 table for instructions on how to communicate with eachrespective engine 712, 714 via the “Malware Engine Selection Module”418. The code segment will then execute those instructions with theassistance of the “Configuration Control Module” 424 and launch theprocesses necessary to perform the updating and ensure that it iscompleted without error. Any problems encountered in this process willbe reported to the user via the “Alerts Module” 404. In each case, thesource of the data applied as updates will be Internet downloads fromthe malware engine's respective support web site.

When the function associated with menu option [24] 268 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Database Module 410    -   (d) Malware Engine Selection Module 418    -   (e) CL/GUI Interface to Malware Engine #X 426 . . . 430    -   (f) Malware Engine(s) 712, 714    -   (g) Alerts Module 404    -   (h) Configuration Control Module 424        Menu Line: [25] Select malware engine(s) to be used in scanning        process 270

Purpose: Selecting the menu option at line [25] 270 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select one or more malware scanning engines for use in apending malware scanning process that will be launched against theforensic image(s) 432, 436. Note that each malware scanning engine 712,714 is hosted by a different and independent virtual operating system704 in a virtual support environment 702 as described in FIG. 16. Theselection function performed is therefore a process that identifieswhich of the respective malware engines will be enabled or disabled asrequired based on the user's actions. This code segment is asub-component of the larger “Master Control Point Dashboard Module” 402application which hosts all of the custom designed menu functionspresented in FIG. 06. The code segment for “Menu Option [25]” 270 isunique in that it is designed to have the ability to communicate withevery malware engine at the command line (CL) interface level, or ifnecessary, directly with the graphical user interface (GUI) 426 . . .430 of the respective malware engine interface 712, 714. This activityis supported by the custom designed functions built into the“Configuration Control Module” 424, the “Malware Engine SelectionModule” 418 and the “Database Module” 410 which permit the user'sselections to be saved in the database and then executed via the codesegment associated with “Menu Option [24]” 270. Any problems encounteredin this process will be reported to the user via the “Alerts Module”404.

When the function associated with Menu Line Option [25] 270 is invokeddata in the form of command and control signals will flow between/amongthe following operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Configuration Control Module 424    -   (g) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 428    -   (h) Malware Engine(s) 712, 714        Menu Line: [26] Configure operational aspects of malware        engine(s) selected 272

Purpose: Selecting the menu option at line [26] 272 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to modify the operational configuration of any malware engineselected for use (by Menu Option [25-NEW] 270 above), for the purposesof enabling or disabling, specific features of each malware engine 712,714 selected as depicted in FIG. 16. This function permits the user todirectly communicate with each independent malware engine 712, 714 ashosted in its respective instance of a virtual operating system 704 viathe “Malware Engine Selection Module” 418 and the respective “CL/GUIInterface to Malware Engine #X 426 . . . 430. Changes made by invokingthis menu option are temporary and are lost when the “Master ControlPoint Dashboard Module” 402 is shut down and are not automatically savedin the “Database Module” 410 by the “Configuration Control” Module 424.Any problems encountered in this process will be reported to the uservia the “Alerts Module” 404.

When the function associated with menu option [26] 272 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Malware Engine Selection Module 418    -   (e) Configuration Control Module 424    -   (f) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430    -   (g) Malware Engine(s) 712, 714        Menu Line: [27] Save/load operational configuration created for        future use 274

Purpose: Selecting the menu option at line [27] 274 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to save or restore the operational configurations of anymalware engine 712, 714 enabled for use. During configuration (per MenuOption [26] 272 above) any features selected by the user areautomatically recorded in a table in the Database Module 410 by the“Configuration Control Module” 424 which is hosted by the “MasterControl Point Dashboard Module” 402. The configuration of eachindependent malware engine is then stored for future use in reportscreated via the “Reports Module” 414, as well as the creation of thelast known good malware engine configuration which is stored in the“Database Module” 410 by the “Configuration Control Module” 424. Thestorage of the last known good malware engine configuration allows thisdata to be restored where necessary to one or more malware engines 712,714. Any problems encountered in this process will be reported to theuser via the “Alerts Module” 404.

When the function associated with menu option [27] 274 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Reports Module 414    -   (f) Configuration Control Module 424    -   (g) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430    -   (h) Malware Engine(s) 712, 714        Menu Line: [28] Select the partition(s) from the mounted images        to be scanned 276

Purpose: Selecting the menu option at line [28] 276 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select which partitions (logical or physical) that have beendiscovered in the “Forensic Image” 432 will be scanned for maliciouscode infections. Access to the “Forensic Image” 432 is provided throughthe “Master Control Point Dashboard Module” 402 and the associated codesegments related to the functions of the “Malware Engine SelectionModule” 418 and the “CL/GUI Interface to Malware Engines #X 426 . . .430 and the malware engines themselves 712, 714. Physical partitions areselected for mounting using “Menu Option [04]” 228 and logicalpartitions are selected for mounting using “Menu Option [06]” 232.Logical identifiers for mounted partitions/volumes are selected using“Menu Option [05]” 230. “Menu Option [28]” 276 requires that the userhas per-selected at least one physical or logical partition/volume formounting using menu options [04] 228, [05] 230 or [06] 232. As notedpreviously code segments for these three menu options are in the publicdomain. Once invoked “Menu Option [28]” 276 will present the user with acheck list of available partitions, logical devices and storage volumes.Checked items that reflect the user's selection are saved by the“Configuration Control Module” 424 in a scan-table in the “DatabaseModule 410.” Any problems encountered in this process will be reportedto the user via the “Alerts Module” 404.

When the function associated with menu option [28] 276 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Configuration Control Module 424    -   (g) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430    -   (h) Malware Engine(s) 712, 714    -   (i) Forensic Image 432        Menu Line: [29] Initialize malware scanning engine(s) 278

Purpose: Selecting the menu option at line [29] 278 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it performssystem pre-checks designed to verify that the operational environmentsupported by the “Host Operating System” 400 is properly configured withthe appropriate resources necessary to run the malware scanningengine(s) on the partitions selected using “Menu Option [28] 276. Forexample, the “Virtual Support Environment” 702 and the “Instances ofVirtual Operating Systems” 704 that host the “Malware ScanningEngine(s)” 712, 714 as described in FIG. 16 are sensitive to the amountof disk space and RAM memory allocated to each from the parent “HostOperating System” 400. The code segment associated with “Menu Option[29]” 278 is a custom designed analysis program that evaluates theresources committed to the various components of the virtual environmentand makes recommendations for possible configuration changes to the userin the form of reports generated by the “Alerts Module”. During thisevaluation process the “Configuration Control Module” 424 queries the“Database Module” 410 in response to the commands originating from thecode segment for “Menu Option [29] 278 to determine which malwareengines are presently selected 712, 714. Once that is established the“Master Control Point Dashboard Module” 402 contacts the “Malware EngineSelection Module” 418 and queries the respective “CL/GUI Interface toMalware Engine #X” 426 . . . 430 so that the current configuration ofthe virtual operating system 704 can be reviewed. In addition, thecurrent operational parameters of the “Host Operating System” 400 andthe “Virtual Support Environment” 702 are also examined. Using customdesigned algorithms the code segment for “Menu Option [29] 278 analysesall operational parameters and makes recommendations to the user on thebest means possible to initialize the malware engines 712, 714 and theirenvironment so maximum productivity is realized. The user is advised ofthese recommended findings via the “Alerts Module” 404.

When the function associated with menu option [29] 278 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Configuration Control Module 424    -   (g) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430    -   (h) Malware Engine(s) 712, 714        Menu Line: [30] Register new malware scanning engine(s) 280

Purpose: Selecting the menu option at line [30] 280 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to register new scanning engines for future use. This action isbasically an inventory update to data maintained in the “DatabaseModule” 410 concerning the type of malware scanning engine available foruse and its operational features. In addition, the registration processallows the users to annotate specific details concerning thecapabilities of each malware engine so that these features can beenabled/disabled by the user as a default operational configuration. Thecode segment from “Menu Option [30]” 280 is designed to accomplish thisregistration process by interacting with the “Configuration ControlModule” 424, which in turns populates the “Database Module” 410 withoperational details that are obtained from the user, as well asoperational feedback obtained from launching the malware engines 712,714 in a test environment. The test environment is facilitated by codesegments associated with “Menu Option [30]” 280 that communicates withthe “Master Control Point Dashboard 402, which in turn instructions the“Malware Engine Selection Module” 418 to select the appropriatecombination of “CL/GUI Interface to Malware Engine #X” 426 . . . 430 andmalware engine 712 714 modules for testing. The user is advised of theresults obtained as well as any problems encountered via the “AlertsModule” 404.

When the function associated with “Menu Option [30]” 280 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430        Menu Line: [31] Unregister current malware scanning engine(s)        282

Purpose: Selecting the menu option at line [31] 282 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select and remove all operational data concerning a malwareengine 712, 714 that has been previously registered. This menu option isspecifically designed to reverse the malware engine registration processdetailed above in the description of “Menu Option [30]” 280. In thiscase, the code segment associated with “Menu Option [31]” 282communicates to the “Master Control Point Dashboard” 402, which in turncommunicates to the “Configuration Control Module” 424 instructions thatresult in queries being sent to the “Database Module” 410 that result inthe purging of all data related to the malware engine selected forelimination. The user is advised of the purging results as well as anyproblems encountered via the “Alerts Module” 404.

When the function associated with “Menu Option [31]” 282 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424        Menu Line: [32] Purge malware engines of all previous reports &        findings 284

Purpose: Selecting the menu option at line [32] 284 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to selectively delete log files and internal reports producedby the malware engines 712, 714 registered for use (per “Menu Option[30]” 280). The logs and reports in question are pre-programmed by themalware engine vendors as either default reports or specialized reports.Regardless of the type of report, those logs or reports that can beindividually selected are controllable thru the use of “Menu Option[30]” 280, the registration process. At issue here is that these malwareengines 712 714 are used and reused numerous times on a daily basis,scanning different forensics images 432 436. To prevent the possibilitythat a log or report from a previous scan can be mistakenly included asa report or log generated by a pending scheduled scan there needs to bea function capable of wiping all former reports generated by the malwareengines 712, 714 prior to starting a new malware scan. The code segmentassociated with “Menu Option [32]” 284 is designed to access eachmalware engine 712, 714 independently and configure the malware engineitself 712, 714, as well as its “Instance Of A Virtual Operating System”704 so that existing logs and reports in designated folders, as well asinternal configuration parameters can be reset so that all previous logsand reports are wiped from the system. To accomplish this goal the codesegment associated with “Menu Option [32] 284 communicates to the“Master Control Point Dashboard” 402, which in turn requests the“Configuration Control Module” 424 to query the “Database Module” 410for default-table data on what internal reports and logs exist on thisspecific malware engine. This data would have been created when the userselected and executed “Menu Option [26]” 272 and “Menu Option [30]” 280.With the operational parameters of the respective malware engine in handthe code segment would then use the “Malware Engine Selection Module”418 to select the appropriate “CI/GUI Interface to Malware Engine #X”426 . . . 430 and malware engine 712, 714 so that it could becommunicated to directly via command line (CL) options or the GraphicalUser Interface (GUI). Once the communication channel was establishedcommands would be issued by the code segment associated with “MenuOption [34]” 284 directly to the malware engine to wipe all reports andlogs. The user is advised of the purging results as well as any problemsencountered via the “Alerts Module” 404. Note that the logs and reportswiped are not part of the “Database Module” 410, but rather are found inspecific folders in the logical storage devices allocated to the“Malware Scanning Engines” 712, 714 in their respective instances of the“Virtual Operating System” 704 as supported by the “Virtual SupportEnvironment” 702 per FIG. 16.

When the function associated with menu option [32] 284 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Configuration Control Module 424    -   (g) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430    -   (h) Malware Engine(s) 712, 714        Menu Line: [33] Adjust configuration to compensate for        unexpected anomalies 286

Purpose: Selecting the menu option at line [33] 286 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to control, at a very granular level, the execution of all codesegments launched thru, from or by the “Master Control Point DashboardModule” 402. This menu option function is basically a troubleshootingcapability that supports code debugging so that unanticipated errors canbe resolved. All of the code segments associated with all of the modulespresented in FIG. 13 are compiled with a “DEBUG” flag that by default isturned off. The code segment associated with “Menu Option [33]” 286turns this “DEBUG” flag on for all modules, allowing the user to singlestep through the code or to set arbitrary breakpoints at locationsthroughout the code for the purposes of troubleshooting errors. Thesetrigger points can be logical points associated with the process itself,or specific module functions, or both. Options in this process arepresented to the user via the “Alerts Module” 404. It is assumed thatinsights gained from this troubleshooting effort will allow the user toadjust the operational configuration of the scanning process tocompensate for unexpected problems.

When the function associated with “Menu Option [33]” 286 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404        The purpose of such a menu option would be to return to prior        menu options to adjust for unexpected results.

FIG. 10 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Scan Control” 214 as shown inFIG. 06:

-   -   [34] Verify forensic images or storage devices are logically        mounted 288    -   [35] Select the start sequence of the different malware engines        290    -   [36] Select the time delay between start sequences 292    -   [37] Enable/disable watchdog timers for malware engines selected        294    -   [38] Configure alert notifications 296    -   [39] Start malware scanning engine(s) 298    -   [40] Pause malware scanning engine(s) 300    -   [41] Reset malware scanning engine(s) 302    -   [42] Stop malware scanning engine(s) 304

According to one arrangement, a function of the “Scan Control” menuoptions in FIG. 10 includes nine menu options (lines [34] through [42]288 . . . 304) that allow the user to control, at a granular level, allactivity related to the running of the multiple malware scanning enginesin parallel as well as confirming the integrity of the forensicobject(s) they will be scanning. The “Scan Control” 214 functions aredependent on the default functions of the “Configuration Control Module”424 and the “Malware Engine Selection Module” 418 presented in theoverview of the “Master Control Point Dashboard” module 402 in FIG. 13,which is discussed in detail starting with paragraph [1332]. All of themenu options, and their related functions, detailed in FIG. 10 areunique with respect to the claims of the present invention.

The nine menu options identified above and in FIG. 10 are customdesigned scripts and applications that are unique to the presentinvention.

Menu Line: [34] Verify forensic images or storage devices are logicallymounted 288

Purpose: Selecting the menu option at line [34] 288 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select and then verify that the logical storage devices, asfound in the forensic images 432, 436, that need to be scanned, aremounted correctly within the Windows environment as operational logicaldevices. Note: This is the last configuration check prior to startingthe scanning process. The code segment associated with “Menu Option[34]” 288 is designed to communicate independently with the respective“Instance Of The Virtual Operating System” 704 to ensure that previousactions executed by “Menu Option [06]” 232 have been successful and thedigital storage device(s) previously selected is/are ready to bescanned. To accomplish this task the code segment associated with “MenuOption [34]” 288 establishes a communication channel with the “MasterControl Point Dashboard Module” 402, which in turn communicates with the“Configuration Control Module” 424, which queries the “Database Module”410 to determine which partitions in the forensic image(s) 432, 436 havebeen previously mounted as logical devices through the execution of“Menu Option [06]” 232. This list is then compared to the user's logicalselections made previously with respect to “Menu Option [34]” 288, suchthat matches that occur are tested to confirm their operational status.This test is accomplished by first enabling “Malware Engine SelectionModule” 418 to provide a communications path through the “CL/GUIInterface to Malware Engine #X” 426 . . . 430 to the “Instance Of TheVirtual Operating System” 704 that is currently supporting one of the“Malware Scanning Engines” 712 714. Once connected to the appropriate“Instance Of The Virtual Operating System” 704 the code segmentassociated with “Menu Option [34]” 288 confirms that command lineutilities and functions compatible with the “Host Operating System” 400can communicate with the logical device. The user is advised of thetesting results as well as any other problems encountered via the“Alerts Module” 404.

When the function associated with “Menu Option [34]” 288 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430    -   (i) Forensic Image 432    -   (j) Forensic image of deleted items recovered on the temp.        storage device 436        Menu Line: [35] Select the start sequence of the different        malware engines 290

Purpose: Selecting the menu option at line [35] 290 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select the starting sequence for all the enabled “MalwareScanning Engines” 712, 714. The selection and enabling of the respectivemalware engines would have occurred when the user previously executed“Menu Options [25]” 270 and “Menu Options [29]” 278. This menu optionaddresses the problem where launching multiple “Malware ScanningEngines” 712, 714 at the same time results in system hangs and crashesdue to the allocation of limited resources (hard disk space and RAMmemory). This problem is resolved by configuring the “Virtual SupportEnvironment” 702 to only start the next “Instance Of The VirtualOperating System” 704 after the previous instance has become fullyoperational. This scheduling task is facilitated by the code segmentassociated with “Menu Option [35]” 290 such that it communicates withthe “Master Control Point Dashboard Module” 402 in such a manner thatthe “Configuration Control Module” 424 updates the startup-a specifictable in the “Database Module 410 that is used to control the startupsequence of the virtual operating system instances. By default, thisstartup-table is configured to start all “Instances Of The VirtualOperating System” 704 at the same time. “Menu Option [35]” 290 allowsthat default status to be changed as required by the user. The user isadvised of the start-up scheduling reconfiguration results as well asany other problems encountered via the “Alerts Module” 404.

When the function associated with “Menu Option [35]” 290 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Configuration Control Module 424    -   (f) Malware Engine(s) 712, 714        Menu Line: [36] Select the time delay between start sequences        292

Purpose: Selecting the menu option at line [36] 292 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select the time delays imposed between the starting sequencefor all the enabled “Malware Scanning Engines” 712, 714. The selectionand enabling of the respective malware engines would have occurred whenthe user previously executed “Menu Options [25]” 270 and “Menu Options[29]” 278. This particular menu option addresses the problem oflaunching multiple “Malware Scanning Engines” 712, 714 at the same timewhich can result in system hangs and crashes due to the allocation oflimited resources (hard disk space and RAM memory). This problem isresolved by configuring the “Virtual Support Environment” 702 to onlystart the next “Instance Of The Virtual Operating System” 704 after aspecific time period has elapsed as selected by the user. Thisscheduling task is facilitated by the code segment associated with “MenuOption [36]” 292 such that it communicates with the “Master ControlPoint Dashboard Module” 402 in such a manner that the “ConfigurationControl Module” 424 updates the startup-table in the “Database Module410 that is used to control the time delay between the startup sequencesof the virtual operating system instances 704. By default, thestartup-table is configured to start all “Instances Of The VirtualOperating System” 704 at the same time. “Menu Option [36]” 292 allowsthat default status to be changed as required by the user. The user isadvised of the time delay scheduling reconfiguration results as well asany other problems encountered via the “Alerts Module” 404.

When the function associated with “Menu Option [36]” 292 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Configuration Control Module 424    -   (f) Malware Engine(s) 712, 714        Menu Line: [37] Enable/disable watchdog timers for malware        engines selected 294.

It is noted that a watchdog timer is an electronic timer that is used todetect and recover from computer malfunctions. During normal operation,the computer regularly restarts the watchdog timer to prevent it fromelapsing, or “timing out”. If, due to a hardware fault or program error,the computer fails to restart the watchdog, the timer will elapse andgenerate a timeout signal. The timeout signal is used to initiatecorrective action or actions. The corrective actions typically includeplacing the computer system in a safe state and restoring normal systemoperation. Watchdog timers are commonly found in computer-controlledequipment where humans cannot easily access the equipment or would beunable to react to faults in a timely manner. Source:http://en.wikipedia.org/wiki/Watchdog_timer

Purpose: Selecting the menu option at line [37] 294 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to enable or disable watchdog timers for each “Malware ScanningEngine” 712, 714 previously selected for use by the user via “MenuOption [25]” 270. By default, watchdog timers are annotated as“disabled” in the watchdog-table in the “Database Module” 410. Duringthe initialization phase of the “Malware Scanning Engines” 712, 714, asinitiated by the user's execution of “Menu Option [29] 278, the “MasterControl Point Dashboard Module” 402 communicates with the ConfigurationControl Module 424, which then queries the aforementionedwatchdog-control table in the “Database Module” 410 to determine if thewatchdog timers should be enabled for the respective malware enginescurrently being initialized. The code segment associated with thisspecific menu option is the only means by which the default “disabled”status can be changed to “enabled.” “Menu Option [37]'s” 294 purpose isto toggle the status of the watchdog timer at the request of the user.If a watchdog timer is enabled for one or more malware engines, by theuser, this watchdog function is made operational prior to the startingof the respective “Malware Scanning Engines” 712, 714 as facilitated by“Menu Option [39] 298. Should a watchdog timer be enabled and then foundto have “timed out” due to operational issues, the user would benotified of this event via the Alerts Module 404.

When the function associated with “Menu Option [37]” 294 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Configuration Control Module 424    -   (f) Malware Engine(s) 712, 714        Menu Line: [38] Configure alert notifications 296

Purpose: Selecting the menu option at line [38] 296 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select how he or she should be notified of events related tothe operation and execution of all menu options. By default, anotification-table exists in the “Database Module” 410. During theinstallation of the software that is the embodiment of the presentinvention, this table is set to “console mode.” Console mode is limitedto communications to and from the primary screen display and thekeyboard. The code segment associated with “Menu Option [38]” 296 allowsthe user to repopulate this notification-table with notificationparameters that are applicable to the operation of all “Malware ScanningEngines” 712, 714 enabled, or it can be configured at a much moregranular level such that different notification techniques areassociated with specific malware engines. For example, thenotification-table entry associated with Malware Scanning Engine #1 canbe configured to only use the console for notifications, while MalwareScanning Engine #2 can be configured to use a specific e-mail addressfor all notifications. In another case, Malware Scanning Engine #3 canbe configured to use both console and e-mail notification techniques.Regardless of the selections made, the user's choices are communicatedby this code segment to the “Master Control Point Dashboard Module” 402which in turn communicates to the “Configuration Control Module” 424advising it to query the “Database Module” 410 and modify thenotification-table parameters as required based on the user'smodification requests. During the startup of the “Master Control PointDashboard” 200 by the Host Operating System 400 this notification-tableis queried to determine past advisements and put those choices are putin place as default values for each of the respective malware engines.

When the function associated with “Menu Option [38]” 296 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Configuration Control Module 424    -   (f) Malware Engine(s) 712, 714        Menu Line: [39] Start malware scanning engine(s) 298

Purpose: Selecting the menu option at line [39] 298 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it verifiesthat all required pre-processing for malware scanning has been completedby the user and the process is ready to be started. The code segmentassociated with “Menu Option [39]” 298 is basically a dynamic check listof six items that is designed to verify that the following major taskshave been initialized and configured in such a manner that the malwarescanning process can be initiated without encountering any errors.

Those major tasks are:

{01} That a forensic image 432 of the digital storage device suspectedof being infected has been acquired and has been mounted as a logicaldevice and at least one logical partition has been selected for scanning(FIG. 07).

{02} That if required, the forensic image 432 has been analyzed for theexistence of deleted items and those items recovered so that they can beconverted to a forensic image of deleted items 436 for later analysis(FIG. 08).

{03} That the malware scanning engines 712, 714 have been registered andconfigured for proper operation. Proper operation includes verificationthat all malware scanning engines have the most recent signature updatesas well as application versions. Proper configuration also includes thepurging of all previous reports internally generated by the malwareengines. In addition, the process verifies that the selected operationalparameters have been saved for future reference. Lastly, this stepre-confirms that at least one of the partitions found within theforensic images 432 436 has been selected for malware scanning (FIG.09).

{04} That the watchdog timers 294 have been properly configured (ifrequired) and that the startup sequence of the malware scanning engines,along with startup time delays have been properly configured for use. Inaddition, this check list step verifies that the parameters associatedwith the alert notifications are capable of communicating to the user asenvisioned (FIG. 10).

-   -   {05} That the real time monitor process has been properly        configured so that the user can monitor the entirety of the        malware scanning process or specific engines from different        perspectives without generating any errors. In addition, this        check list step also tracks that alerts of an urgent nature, if        requested by the user, have been identified as having priority        status with respect to the alerts notification system (FIG. 11).    -   {06} That the system has to ability to communicate to the proper        ports and devices for the purpose of producing formal and        informal reports. In addition, this check list system also        verifies that test reports can be saved and deleted as well as        normalized (when required) with respect to naming conventions        for known viruses and malicious code infections. Also verified        is that keyword searches can be run against historical test        reports that are in the database archive, producing results as        anticipated. Lastly, using test data the check list process        verifies that statistical projections can be made within        acceptable parameters (FIG. 12).        These operational items are verified by the code segment        associated with “Menu Option [39]” 298 by making queries to the        “Database Module” 410 through the “Master Control Point        Dashboard Module” 402 and the “Configuration Control Module 424.        All of the above check list items are tables in the “Database        Module 410. As the check list items in each table are satisfied        and confirmed to be operational, a “good-to-go” ranking is        established for all malware scanning engines selected. Once all        malware scanning engines selected for use have achieved this        status a single “GO” command is generated by this code segment        using the following signal path: “Master Control Point Dashboard        Module 402” to “Malware Engine Selection Module” 418 to each        respective (user selected) “Command Line/Graphical User        Interface to Malware Engine #X” 426 . . . 430 and “Malware        Scanning Engine” 712, 714. When the “GO” signal command is        received each malware scanning engine executes per its        respective configuration. The user is advised of any problems        encountered via the “Alerts Module” 404.

When the function associated with “Menu Option [39]” 298 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430    -   (i) Forensic Image 432    -   (j) Forensic image of deleted items recovered on the temp.        storage device 436        Menu Line: [40] Pause malware scanning engine(s) 300

Purpose: Selecting the menu option at line [40] 300 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that a signal canbe sent to one or more “Malware Scanning Engines” 712, 714 for thepurpose of pausing the scanning process. When the code segmentassociated with “Menu Option [40]” 300 is executed by the user thefollowing sequence of events occurs. The “Master Control Point DashboardModule” 402 is communicated with and advised that a pause signal needsto be sent to one or more malware scanning engines. The “Master ControlPoint Dashboard Module” 402 queries the “Configuration Control Module”424 which in turns sends a query to the “Database Module” 410 requestingdetails on all malware engines currently running scans. The datareturned to the “Configuration Control Module” 424, in the form of therunning-table, quantifies which engines are running and therefore arecapable of being paused. The “Configuration Control Module” 424 thenadvises the “Master Control Point Dashboard Module” 402 that it needs tosend one or more pause signals to the respective malware scanningengines. The “Master Control Point Dashboard Module” 402 then uses the“Malware Engine Selection Module” 418 to select the appropriate “CommandLine/Graphical User Interface to Malware Engine #X” 426 . . . 430 whichin turn, accesses the appropriate “Malware Scanning Engine” 712, 714 andissues a pause signal. Upon receipt of the pause signal the “MalwareScanning Engine” 712, 714 enters a “paused state” awaiting furtherinstructions. The user is advised of any problems encountered via the“Alerts Module” 404.

When the function associated with “Menu Option [40]” 300 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430        Menu Line: [41] Reset malware scanning engine(s) 302

Purpose: Selecting the menu option at line [40] 300 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that a signal canbe sent to one or more “Malware Scanning Engines” 712, 714 for thepurpose of resetting the scanning process to a known operational state.Typically, the reset status takes each of the malware scanning enginesto a state equivalent to a new install. When the code segment associatedwith “Menu Option [41]” 302 is executed by the user the followingsequence of events occurs. The “Master Control Point Dashboard Module”402 is communicated with and advised that a reset signal needs to besent to one or more malware scanning engines. The “Master Control PointDashboard Module” 402 queries the “Configuration Control Module” 424which in turns sends a query to the “Database Module” 410 requestingdetails on all malware engines currently running scans. The datareturned to the “Configuration Control Module” 424, in the form of therunning-table, quantifies which engines are running and therefore arecapable of being reset. The “Configuration Control Module” 424 thenadvises the “Master Control Point Dashboard Module” 402 that it needs tosend one or more reset signals to the respective malware scanningengines. The “Master Control Point Dashboard Module” 402 then uses the“Malware Engine Selection Module” 418 to select the appropriate “CommandLine/Graphical User Interface to Malware Engine #X” 426 . . . 430 whichin turn, accesses the appropriate “Malware Scanning Engine” 712, 714 andissues a reset signal. Upon receipt of the reset signal the “MalwareScanning Engine” 712, 714 enters a “reset state” awaiting furtherinstructions. The user is advised of any problems encountered via the“Alerts Module” 404.

When the function associated with “Menu Option [41]” 302 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430        Menu Line: [42] Abort malware scanning engine(s) 304

Purpose: Selecting the menu option at line [40] 300 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that a signal canbe sent to one or more “Malware Scanning Engines” 712, 714 for thepurpose of stopping the scanning process. When the code segmentassociated with “Menu Option [42]” 304 is executed by the user thefollowing sequence of events occurs. The “Master Control Point DashboardModule” 402 is communicated with and advised that a stop signal needs tobe sent to one or more malware scanning engines. The “Master ControlPoint Dashboard Module” 402 queries the “Configuration Control Module”424 which in turns sends a query to the “Database Module” 410 requestingdetails on all malware engines currently running scans. The datareturned to the “Configuration Control Module” 424, in the form of therunning-table, quantifies which engines are running and therefore arecapable of being stopped. The “Configuration Control Module” 424 thenadvises the “Master Control Point Dashboard Module” 402 that it needs tosend one or more stop signals to the respective malware scanningengines. The “Master Control Point Dashboard Module” 402 then uses the“Malware Engine Selection Module” 418 to select the appropriate “CommandLine/Graphical User Interface to Malware Engine #X” 426 . . . 430 whichin turn, accesses the appropriate “Malware Scanning Engine” 712, 714 andissues a stop signal. Upon receipt of the stop signal the “MalwareScanning Engine” 712, 714 enters a “stopped state” awaiting furtherinstructions. The user is advised of any problems encountered via the“Alerts Module” 404.

When the function associated with “Menu Option [42]” 304 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Database Module 410    -   (e) Malware Engine Selection Module 418    -   (f) Malware Engine(s) 712, 714    -   (g) Configuration Control Module 424    -   (h) Command Line/Graphical User Interface to Malware Engine #1        426 . . . 430

FIG. 11 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Monitor Process” 216 as shown inFIG. 06.

-   -   [43] Select malware scanning engine(s) to monitor 306    -   [44] Select 2D or 3D graphical display for use in monitoring 308    -   [45] Set refresh frequency of monitoring process 310    -   [46] Select granularity of monitoring controls 312    -   [47] Create statistical projections on time to complete scanning        314    -   [48] Monitor memory usage and hard drive transfer rates 316    -   [49] Display count of malicious code instances found so far 318    -   [50] Rate infections found so far by severity classifications        320    -   [51] Detect anomalous behavior of running platforms and        engine(s) 322    -   [52] Monitor local operating system parameters 324

According to one arrangement, a function of the “Monitor Process” menuoptions in FIG. 11 (lines [43] through [52] 306 . . . 324) are forallowing the user to receive operational updates on the status of allmalicious code scanning related processes presently underway. Theupdates requested by the user can be in real time, or they can be at settime or event specific intervals. Updates generated can be for one ormore malware scanning engines identified as single entities or groupsthat are defined by the user based on some scanning characteristic. The“Monitor Process” 216 functions are dependent on the operationalcapabilities of the “Malware Engine Selection Module” 418 and the“Command Line/Graphical Interface to Malware Engine #X” 426 . . . 430presented in the overview of the “Master Control Point Dashboard” module402 in FIG. 13, which is discussed in detail starting with paragraph[1332]. All of the menu options, and their related functions, detailedin FIG. 11 are unique with respect to the claims of the presentinvention.

The ten menu options identified above and in FIG. 11 are custom designedscripts and applications that are unique to the present invention.

Menu Line: [43] Select malware scanning engine(s) to monitor 306

Purpose: Selecting the menu option at line [43] 306 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select different malware scanning engines 712, 714 formonitoring during the scanning process. The updates requested can besent to the default console display associated with the “Master ControlPoint Dashboard Module” 402 or they can also be routed to a buffer for alarge high-definition (HDMI) “Hardware Monitor Display Buffer” 408 thatis directly controlled by the “Display Controls Module” 406 module. Whenthe user executes “Menu Option [43]” 306 the following internal sequenceof events occurs: The code segment associated with “Menu Option [43]”306 communicates with the “Master Control Point Dashboard Module” 402and advises that the “Configuration Control Module” 424 needs to beupdated to reflect the user's desire to monitor one of more malwarescanning engines 712, 714. In turn, the “Configuration Control Module”424 queries the “Database Module” 410 and requests a list of all malwarescanning engines currently performing a scan. The “Configuration ControlModule” 424 presents the user with this list and allows selections to bemade with respect to the malware scanning engines that have the abilityto be monitored. At this point, the user is offered the opportunity tocreate “groups” of malware scanning engines 712, 714 such that theirindividual status can be combined together such that their individualactivities are reported as one entity. Once the selection process iscompleted the “Configuration Control Module” 424 updates themonitor-table in the “Database Module” 410 with the modifiedinformation. This update triggers the “Master Control Point DashboardModule” 402 to enable a communications path between the malware scanningengines 712, 714 and the “Statistics Module” 416. This path flows fromthe malware scanning engines 712, 714 through the “Instance of TheVirtual Operating System” 704 to the “Command Line/Graphical UserInterface to Malware Engine #X 426 . . . 430 to the “Malware EngineSelection Module” 418 which was previously configured by the “MasterControl Point Dashboard Module” 402 when the trigger occurred. This pathallows all respective data concerning the running malware engine(s) tobe collected, analyzed and averaged for display purposes. The updatedstatistics on engine performance is routed through the “Master ControlPoint Dashboard Module” 402 by the “Statistics Module” 416 to the“Display Control Module” 406 for output to the “Hardware Monitor DisplayBuffer” 408. This monitoring status remains active until changed by theuser. The user is advised of any problems encountered during thisprocess via the “Alerts Module” 404.

When the function associated with menu option [43] 306 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Malware Engine Selection Module 418    -   (i) Malware Engine(s) 712, 714    -   (j) Configuration Control Module 424    -   (k) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430        Menu Line: [44] Select 2D or 3D graphical display for use in        monitoring 308

Purpose: Selecting the menu option at line [44] 308 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select either the default two dimensional (2D) display or athree dimensional (3D) display for monitoring output. This option isprovided as an enhancement as monitoring multiple malware scanningengines 712, 714 simultaneously in 2D can be very confusing at times.Utilizing the 3D option allows charts and graphs to be much morecompelling and informative. The code segment associated with “MenuOption [44]” 308 is designed to allow the user to select either the 2Dor 3D display option. If 3D is selected the raw data feed associatedwith standard 2D displays is converted into a 3D representation. Oncethe 3D option is enabled by the user the modified raw data feed is sentby the “Statistics Module” 416 to the “Display Control Module” 406 foroutput to the “Hardware Monitor Display Buffer” 408. The means by whichthe raw monitoring data is produced for display purposes is identical tothe output produced when “Menu Option [43] 306 is executed and enabled.As a result, the specific details as to how the raw monitoring data isproduced and routed among the various modules associated with the MasterControl Point Dashboard Module 402 are not described here. As always,any problems encountered during this process are communicated to theuser via the “Alerts Module” 404.

When the function associated with “Menu Option [44]” 308 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Malware Engine Selection Module 418    -   (i) Malware Engine(s) 712, 714    -   (j) Configuration Control Module 424    -   (k) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430        Menu Line: [45] Set refresh frequency of monitoring process 310

Purpose: Selecting the menu option at line [45] 310 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select the refresh frequency of real-time updates concerningthe running of the malware scanning engines 712, 714. By default, arefresh-table in the “Database Module” 410 is populated with a defaultrefresh rate of 15 minutes. Under these parameters the “Hardware MonitorDisplay Buffer” 408 is updated by the “Display Control Module” 406,which is updated by the “Statistics Module” 416 which receives updatesfrom the malware scanning engines four times an hour. This code segmentallows the user to modify that 15 minute parameter to whatever timebased value is required. This is accomplished by having this codesegment notify the “Master Control Point Dashboard Module” 402 that the“Configuration Control Module” 424 needs to modify the appropriaterefresh-table in the “Database Module” 410 of the user's modification tothe default values. Once that refresh-table update is accomplished andsaved the refresh rates are locked into place as a new default standarduntil modified by the user by executing “Menu Option [45]” 310. Asalways, any problems encountered during this process are communicated tothe user via the “Alerts Module” 404.

When the function associated with “Menu Option [45]” 310 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Malware Engine Selection Module 418    -   (i) Malware Engine(s) 712, 714    -   (j) Configuration Control Module 424        Menu Line: [46] Select granularity of monitoring controls 312

Purpose: Selecting the menu option at line [46] 312 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select the level of granular monitoring for the malwarescanning engines 712, 714. During the initialization of the malwarescanning engines (“Menu Option [29]” 278) and registration process(“Menu Option [30]” 280) the user has the opportunity to identify thevarious features of each malware scanning engine in a feature-table inthe “Database Module” 410. The feature-table allows each reportablefeature of the malware scanning engine 712, 714 to be rated by the userbased on a five-point rating system. Where “1” equals a high level“50,000 foot perspective,” and “5” equals a low level drill downperspective. If the user selects a rating of “1” then only thosefeatures ranked by the user as a “1” will be displayed via the “DisplayControl Module” 406 and “Hardware Monitor Display Buffer” 408. If theuser selects “3” for example, then all feature rankings that include “1”through “3” (including “2”) will be displayed. If “5” is selected, thenall features initially identified in the registration and initializationprocess will be displayed by the monitoring controls as reportablemonitoring events. This granularity selection process controls theamount of information that is reported to the user concerning therunning statistics of each individual malware scanning engine. Theuser's selections are taken by the “Configuration Control Module” 424and routed thru the “Master Control Point Dashboard Module” 402 so thatthe feature-table in the “Database Module” 410 is updated accordingly.As always, any problems encountered during this process are communicatedto the user via the “Alerts Module” 404.

When the function associated with “Menu Option [46]” 312 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Configuration Control Module 424    -   (i) Malware Engine(s) 712, 714        Menu Line: [47] Create statistical projections on time to        complete scanning 314

Purpose: Selecting the menu option at line [47] 314 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to obtain projections on the time remaining to complete amalicious code scan on a forensic image 432 436 using multiple malwarescanning engines 712, 714 simultaneously. This code segment is designed,in conjunction with other modules of the Master Control Point DashboardModule 402, to monitor specific reporting mechanisms of each malwarescanning engine, that report on the projected time required to completethe malicious code scan currently underway, and collect that informationfor analysis. During the initialization of the malware scanning engines(“Menu Option [29]” 278) and registration process (“Menu Option [30]”280) one of the features identified and collected from each malwareengine is the knowledge of what it takes to query the respective malwareengine and have it report on the estimated time required to complete amalicious code scan. To enable this function the code segment associatedwith “Menu Option [47]” 314 notifies the Master Control Point DashboardModule 402 that needs to access the “Statistics Module” 416 and have itprovide a detailed, as well as summary report, on the estimated time tocompletion for the scanning process currently underway. By default, thecode segment associated with the “Statistics Module” 416 has beendesigned to routinely collect estimated time to completion data fromeach malware engine. Once aware that this data has been requested the“Statistics Module” 416 updates the remaining-table with this data andpasses it on to the “Database Module” 410 where it is saved and thensent to the “Display Control Module” 406 in the form of a displayablereport consisting of charts and graphs on each individual malwarescanning engine 712, 714 in operation. The charts and graphs associatedwith this report may be displayed in 3D if the user previously selectedthis mode via “Menu Option [44]” 308. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [47]” 314 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Malware Engine(s) 712, 714    -   (i) Forensic Image 432    -   (j) Forensic image of deleted items recovered on the temp.        storage device 436        Menu Line: [48] Monitor memory usage and hard drive transfer        rates 316

Purpose: Selecting the menu option at line [48] 316 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to get operating system level reports on the hardware resourcesrequired to support the scanning of forensic images 432 436 by multiplemalware scanning engines 712, 714 simultaneously. The code segmentassociated with “Menu Option [48]” 316 is designed to have the abilityto access the “Virtual Support Environment” 702 management consoles andthe “Instances Of The Virtual Operating System” 704 management consolesdirectly for the purpose of querying these internal management resourcesabout the state of their respective hardware resources. In both cases,low level scripts at the command line have been authored to collect thisdata. To clarify, one script is designed to have the ability tocommunicate with the VMWare or Hyper-V support environment 702 andcollect data on each instance of every virtual operating system inplace. The remaining script is designed to communicate with each“Instances Of The Virtual Operating System” 704 to collect data on theoperating system being used to support the malware engine hosted by thisvirtual environment 704. In both cases the data that is collected ispassed on to the hardware-table in the “Database Module” 410 by the“Master Control Point Dashboard Module” 402 and “Configuration ControlModule” 424 for storage and future reference. The “Statistics Module”416 is then put on notice by the code segment associated with “MenuOption [48]” 316 that there is data that needs to be analyzed. The“Statistics Module” 416 analyses the data in context as hardware relatedand passes the analysis results on to the user via the “Display ControlModule” 406. As always, any problems encountered during this process arecommunicated to the user via the “Alerts Module” 404.

When the function associated with “Menu Option [48]” 316 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Database Module 410    -   (f) Statistics Module 416    -   (g) Configuration Control Module 424    -   (h) Malware Engine(s) 712, 714        Menu Line: [49] Display count of malicious code instances found        so far 318

Purpose: Selecting the menu option at line [49] 318 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to obtain a running total of malicious code infections found todate by the malware scanning process currently underway. During themalware scanning process each of the individual malware scanning engines712, 714 that have been selected by the user (“Menu Option [25]” 270) toactively scan the forensic images 432, 436 for infections are constantlyqueried by the “Statistics Module” 416 as to their findings to date.Updates obtained from the “Statistics Module” 416 from the individualmalware scanning engines 712, 714 are stored in the findings-tablelocated in the “Database Module” 410. The “Statistics Module” 416summarizes all this data into a running report that is displayed to theuser based on each malware engine's individual findings. For example, ifthe user had selected that 28 out of 32 malware engines were to be usedfor scanning purposes, a list of 28 engine names would be displayedalong with the total number of malicious code segments discovered duringthe current malicious code scanning process. This overview offindings-to-date is obtained from the individual malware scanningengines 712, 714 in one of three ways. The first approach relies on thecode segment associated with the “Command Line/Graphical User Interfaceto Malware Engine #X” 426 . . . 430 ability to issue command lineinstructions to the engine and have it respond with a current findingsreport. The second approach is to have the “Command Line/Graphical UserInterface to Malware Engine #X” 426 . . . 430 communicate using theGraphical User Interface (GUI) associated with the malware engine andrequest the same information. Lastly, in cases where it is not feasibleto use either of the above approaches, the “Command Line/Graphical UserInterface to Malware Engine #X” 426 . . . 430 reverts to internal codesegments specifically designed to “screen scrape” certain areas of thescreen display produced by the malware engine itself for findingsupdates. Screen scraping is the process of collecting screen displaydata from one application and translating it so that another applicationcan display it. This is normally done to capture data from a legacyapplication in order to display it using a more modern user interface.Screen scraping usually refers to a legitimate technique used totranslate screen data from one application to another. (SOURCE:http://www.techopedia.com/definition/16597/screen-scraping) Onceaccumulated the overall results are sent by the “Statistics Module” 416thru the “Master Control Point Dashboard Module” 402 to the “DisplayControl Module” 406 where using options previously selected by the user(“Menu Option [44]” 308, “Menu Option [45]” 310 and “Menu Option [46]”312) the “Hardware Monitor Display Buffer” 408 uploaded with theappropriate raw data. As always, any problems encountered during thisprocess are communicated to the user via the “Alerts Module” 404.

When the function associated with “Menu Option [49]” 318 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430    -   (i) Malware Engine(s) 712 714        Menu Line: [50] Rate infections found so far by severity        classifications 320

Purpose: Selecting the menu option at line [50] 320 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner to provide theuser with a generalized report on the severity of malicious codeinfections discovered to date by the scanning process currentlyunderway. During the malware scanning process each of the individualmalware scanning engines 712, 714 that have been selected by the user(“Menu Option [25]” 270) to actively scan the forensic images 432, 436for infections are constantly queried by the “Statistics Module” 416 asto the severity classifications assigned by the individual malwarescanning engines 712, 714 to infections discovered to date. Updatesobtained from the “Statistics Module” 416 from the individual malwarescanning engines 712, 714 are stored in the severity-table located inthe “Database Module” 410. These malware engine generated text basedupdates typically include a name for the infection(s) found as well as aseverity ranking, usually a number between 1 and 5 where 5 is the mostsever of the rankings. The “Statistics Module” 416 summarizes all thisdata into a generalized report that is displayed to the user based oneach malware engine's individual rankings of severity. For example, thereport might contain data on the following reportable items: “VendorName, Engine Name, Severity Ranking, Total Amount of Infections At ThisSeverity Level.” This summary data is obtained from the individualmalware scanning engines 712, 714 in one of three ways. The firstapproach relies on the code segment associated with the “CommandLine/Graphical User Interface to Malware Engine #X” 426 . . . 430ability to issue command line instructions to the engine and have itrespond with a current findings report. The second approach is to havethe “Command Line/Graphical User Interface to Malware Engine #X” 426 . .. 430 communicate using the Graphical User Interface (GUI) associatedwith the malware engine and request the same information. Lastly, incases where it is not feasible to use either of the above approaches,the “Command Line/Graphical User Interface to Malware Engine #X” 426 . .. 430 reverts to internal code segments specifically designed to “screenscrape” certain areas of the screen display produced by the malwareengine itself for severity reports. Once accumulated the overall resultsare sent by the “Statistics Module” 416 thru the “Master Control PointDashboard Module” 402 to the “Display Control Module” 406 where usingoptions previously selected by the user (“Menu Option [44]” 308, “MenuOption [45]” 310 and “Menu Option [46]” 312) the “Hardware MonitorDisplay Buffer” 408 is uploaded with the appropriate raw data. Theseverity classification display report is meant to be a quick indicatorof the extent to which the forensic image 432 436 being analyzed hasbeen compromised by malicious code infections. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [50]” 320 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Statistics Module 416    -   (h) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430    -   (i) Malware Engine(s) 712, 714        Menu Line: [51] Detect anomalous behavior of running platforms        and engine(s) 322

Purpose: Selecting the menu option at line [51] 322 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it advisesthe user of anomalous events in either the “Host Hardware Platform” 100,the “Host Operating System” 400, the “Virtual Support Environment” 702,and the individual “Instances Of The Virtual Operating System” 704 andthe “Malware Scanning Engines” 712, 714. Operational data concerning theabove items is constantly monitored by the “Configuration ControlModule” 424 and stored in the operations-table in the “Database Module”410 for future reference. Code segments in the “Configuration ControlModule” 424 are designed to monitor the contents of the appropriate“Event Logs” in each of the monitored entities previously identifiedabove. The event logs monitored by the “Configuration Control Module”424 are analyzed for event log codes known to be an indicator ofanomalous behaviors. This analysis occurs in real time but is notreported unless the user specifically requests this information byexecuting “Menu Option [51]” 322. Once selected, the code segmentassociated with “Menu Option [51]” 322 communicates with the“Configuration Control Module” 424 and requests that data in theoperations-table as found in the “Database Module” 410 be analyzed foranomalous event code behavior. This request triggers the “StatisticsModule” 416 which in turn performs the analysis and creates a reportwhich it sends to the “Display Control Module” 406 for routing to the“Hardware Monitor Display Buffer” 408. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [51]” 322 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Alerts Module 404    -   (c) Display Control Module 406    -   (d) Hardware Monitor Display Buffer 408    -   (e) Database Module 410    -   (f) Statistics Module 416    -   (g) Malware Engine(s) 712, 714    -   (h) Configuration Control Module 424        Menu Line: [52] Monitor local operating system parameters 324

Purpose: Selecting the menu option at line [52] 324 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it creates atechnical report on the operational status of the “Host OperatingSystem” 400. The code segment associated with “Menu Option [52]” 324 wasdesigned to constantly keep track of the technical data produced bytools such as “TaskManager and Powershell” under Windows and “ps, Htopand pstree” under Linux. This constant monitoring is accomplished bycode segments associated with the “Configuration Control Module” 424which has the ability to directly communicate with the “Host OperatingSystem” 400. The output of these tools is saved by the “ConfigurationControl Module: 424 in the host-table in the “Database Module” 410 forfuture reference. The “Statistics Module” 416 is programmed to monitorthe content of the host-table and create an ongoing report of keyperformance parameters. In addition, the “Statistics Module” 416 is alsopre-programmed with upper and lower limits for each key performancefunction monitored. These limits are critical parameters as they havebeen researched extensively by the authors of the present invention asindicators of the most efficient and effective parameters for a “HostOperating System” 400 specifically configured to facilitate a “VirtualSupport Environment” 702. If any of these functions are noted as beingout of band the “Alerts Module” 404 triggers an alert notification tothe user. These alerts continue until the performance issue has beenresolved or the user changes the upper/lower bandwidth constraints.These alerts are in addition to the comprehensive technical report onthe “Host Operating System” 400 that the user can generate on demand byselecting “Menu Option [52]” 324. If a comprehensive technical report isrequested by the user the “Statistics Module” 416 is advised of same bythe “Configuration Control Module” 424. The on-demand report isgenerated by the “Statistics Module” 416 after it analyzes thehost-table maintained in the “Database Module” 410. The report createdis communicated to the “Display Control Module” 406 which in turn passesthe data onto the “Hardware Monitor Display Buffer” 408. Note this datamay be in a 2D or 3D format depending on the type of display selected bythe user with respect to “Menu Option [44]” 308. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [52]” 324 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Alerts Module 404    -   (c) Display Controls 406    -   (d) Hardware Monitor 408    -   (e) Database Module 410    -   (f) Statistics Module 416    -   (g) Configuration Control Module 424

FIG. 12 is a representation of what the user would see when they clickedon either of the menu buttons labeled “Create Reports” 218 as shown inFIG. 06.

-   -   [53] Select malware scanning engine(s) to generate reports on        326    -   [54] Normalize malware data found into common CVE notations 328    -   [55] Select types of reports to generate 330    -   [56] Save reports generated in the malware report archives 332    -   [57] Open saved session reports for review 334    -   [58] Purge old session reports from malware archives 336    -   [59] Compare the infections found in two or more session reports        338    -   [60] Based on “findings to date” project likelihood of more        infections 340    -   [61] Generate report on suggested mitigation strategies 342

According to one arrangement, a function of the “Create Reports” menuoptions in FIG. 12 options (lines [53] through [61] 326 . . . 342) arefor providing the user with formal and informal reports on thediscoveries made to date concerning malicious code infections, as wellas statistical and heuristic projections based on those findings. The“Create Reports” 218 functions are dependent on the operationalcapabilities of the “Reports Module” 414, the “Scanning ResultsNormalization Engine Module” 412, the “Statistics Module” 416 and the“Database Module” 410 presented in the overview of the “Master ControlPoint Dashboard” module 402 in FIG. 13, which is discussed in detailstarting with paragraph [1332]. All of the menu options, and theirrelated functions, detailed in FIG. 12 are unique with respect to theclaims of the present invention.

The nine menu options identified above and in FIG. 12 are customdesigned scripts and applications that are unique to the presentinvention.

Menu Line: [53] Select malware scanning engine(s) to generate reports on326

Purpose: Selecting the menu option at line [53] 326 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it allows theuser to select one or more malware scanning engines 712, 714 to be thesource of reports generated. “Menu Option [53]” 326 is similar in itsscope to “Menu Option [43]” 306, “Select malware scanning engine(s) tomonitor.” They are alike in that they both modify a specific table inthe “Database Module” 410 based on selections made by the user. They aredifferent in that one enables the use of a malware scanning engine([43]), while the other ([53]) enables the accumulation of data for thespecific purpose of generating formal and informal reports. When theuser executes the code segment associated with “Menu Option [53]” 326two actions are initiated. The first sends trigger signals tosubroutines in the following modules: “Master Control Point DashboardModule” 402, “Physical Forensic Acquisition Module” 422, the “DeletedItem Recovery Module” 420, the “Database Module” 410, the “ScanningResults Normalization Engine Module” 412, the “Statistics Module” 416,“Configuration Control Module” 424, the “Malware Engine SelectionModule” 418, and each one of the “Command Line/Graphical User Interfaceto Malware Engine #X” 426 . . . 430 modules, as well as each of therespective “Instances Of A Virtual Operating System” 704 and therespective “Malware Scanning Engines” 712, 714 they support. Each ofthese modules is put on notice that they may be directed to accumulateand distribute operational updates on technical issues germane to theirspecific function in supporting the operation of all the malwarescanning engines 712, 714, as well as infections found. The items to becollected and tracked in each module are pre-programmed into thereports-table after extensive prior research concerning which items tendto impact the accuracy, efficiency, effectiveness and usefulness of thescanning process. The second action triggered is a request to the user,via the “Display Control Module” 406 and “Hardware Monitor DisplayBuffer” 408, asking for a selection to be made that identifies whichmalware engines will be the source of reports generated during thisscanning session. The user's response is saved in a reports-table in the“Database Module” 410 for future reference. The user's selections atthis point do not automatically generate any reports, rather the user'sselections set the stage for the downstream collection and aggregationof data that may be relevant to requests made for future reports. A vastmajority of the preparation work performed here pivots on the creationof temporary tables and keys in the “Database Module” 410 needed to saveand analyze the data targeted for collected. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [53]” 326 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Controls 406    -   (e) Hardware Monitor 408    -   (f) Database Module 410    -   (g) Scanning Results Normalization Engine Module 412    -   (h) Reports Module 414    -   (i) Statistics Module 416    -   (j) Malware Engine Selection Module 418    -   (k) Malware Engine(s) 712, 714    -   (l) Deleted Item Recovery Module 420    -   (m) Physical Forensic Acquisition Module 422    -   (n) Configuration Control Module 424    -   (o) Command Line/Graphical User Interface to Malware Engine #X        426 . . . 430        Menu Line: [54] Normalize malware data found into common CVE        notations 328

Purpose: Selecting the menu option at line [54] 328 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it assiststhe user in normalizing the different naming conventions that are usedto identify malicious code segments among the various malware vendors inboth the public and private sectors. One of the operational issues inusing multiple malware scanning engines 712, 714 to scan the sameforensic image 732, 736 of a computer system suspected of being infectedis that each malware vendor uses their own proprietary naming conventionto describe the infections found. As a result, it is not uncommon todiscover that many different malware scanning engines find the exactsame instance of a malicious code infection but call it somethingdifferent. This differential then makes it appear, when reviewing thefindings made, that there are more infections than there actually are.To resolve this issue the code segment associated with “Menu Option[54]” 328 is designed to recognize these discrepancies and append theoriginal names provided with one that has a common notation, such as the“Common Vulnerabilities and Exposures” (CVE) naming convention(http://cve.mitre.org/index.html). Conversion of vendor created namingconventions to the CVE index is a detailed process that requiressubstantial discussion. As a result, a figure has been created to assistin that overview. Please see the written description associated withFIG. 18 for additional details on this function.

When the function associated with “Menu Option [54]” 328 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Data Flow List Not Applicable: See FIG. 18 for enhanced        details.        Menu Line: [55] Select types of reports to generate 330

Purpose: Selecting the menu option at line [55] 330 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select the type of reports to be generated for each malwarescanning engine 712, 714 selected via “Menu Option [25]” 270 to beutilized in the scanning process. The user is presented with a checklistof different report types for each malware engine via data sent to the“Display Control Module” 406. The report types selected by the user arestored in the types-table in the “Database Module” 410 by the “MasterControl Point Dashboard Module” 402. A few examples of the manydifferent types of generalized and specific reports the user can selectto be generated for each malware engine are: Malware Found, VirusesFound, Trojans Found, Spear Fishing Found, Harmful IP Addresses Found,Harmful URLs Found, Infected E-mails, Malware Engine OperationalParameters (total files scanned, total malware infections found, totalrunning time, total size of files scanned, etc.), Malware EngineRevision Level, Malware Engine Signature Level, SeverityClassifications, Files Currently In Quarantine, Time Since The LastSignature Update was performed and Ad Hoc Queries created by the user.The types of reports selected here are global to the present inventionin that their selection, of lack thereof, determines if other moduleswith built-in report capability will produce and display reports wherethose reports have content that is similar to those described in thepre-programmed types-table. As always, any problems encountered duringthis process are communicated to the user via the “Alerts Module” 404.

When the function associated with “Menu Option [55]” 330 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Controls 406    -   (e) Hardware Monitor 408    -   (f) Database Module 410    -   (g) Malware Engine(s) 712, 714        Menu Line: [56] Save reports generated in the malware report        archives 332

Purpose: Selecting the menu option at line [56] 332 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to save all reports generated during the current scanningsession to the “Database Module” 410 in the session-table. The currentscanning session is defined as started once the user invokes “MenuOption [39]” 298, “Start malware scanning engine(s),” and stopped whenthe user invokes “Menu Option [42]” 298, “Stop malware scanningengine(s).” Requests to save all generated reports are passed on to the“Reports Module” 414 which maintains a list of all recent reportsgenerated during the current session. The “Reports Module” 414 isresponsible for collecting all the details on these reports andinforming the “Database Module” 410 that a session based archive willneed to be created that includes “X” files with a total size of “Y.” Incases were summary data needs to be created because one or more of themodules has not yet completed the entire scan the “Statistics Module”416 is included in the process to generate the required summary data.Once the “Database Module” 410 advises the “Reports Module” 414 that itis ready to assimilate all the report data available the “ReportsModule” 414 queries all other modules for the data and routes theappropriate data to the “Database Module” 410 session-table for archivalstorage. Keys in the session-tables have a unique naming convention thatlinks the primary key to a specific date and time format along withdetailed source information. These session based archives will be usedin later menu options to compare malicious code findings and detail theoperational parameters in place when they were found. This task iscompleted without any user interaction. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [39]” 332 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Alerts Module 404    -   (c) Database Module 410    -   (d) Reports Module 414    -   (e) Statistics Module 416        Menu Line: [57] Open saved reports for review 334

Purpose: Selecting the menu option at line [57] 334 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to select archived session reports created using “Menu Option[39]” 332 (above) for review. The code segment associated with “MenuOption [57]” 334 is designed to be used in conjunction with the “MasterControl Point Dashboard Module” 402 to access the “Database Module” 410and review records in the session-table. The user is provided withmultiple searching and display options that permit historical data inthe session-table to be analyzed after the fact based on numerousdifferential criteria. The searching performed is assisted by code inthe “Statistics Module” 416 if the user's search criteria requires thatsummary data be generated across multiple sessions. Informal reports aregenerated directly by the code segment associated with “Menu Option[57]” 334 and passed on to the “Display Control Module” 406 forpresentation. Requests for formal session reports by the user are routedto the “Reports Module” 414 which uses pre-defined and ad hoc templatesto present the data in meaningful graphical formats. In cases where thesummary reports requested contain the names of malware discovered the“Scanning Results Normalization Engine Module” 412 may be accessed forthe purpose of consolidating data concerning malware discovered. The“Reports Module” 414 routes the completed formal reports to the “DisplayControl Module” 406 for presentation. Reports pre-classified as“complex” are converted to 3D chart formats prior to being sent to the“Display Control Module” 406 if the user has enabled this capabilityusing “Menu Option [55]” 330. As always, any problems encountered duringthis process are communicated to the user via the “Alerts Module” 404.

Menu Line: [57] Open saved session reports for review 334

When the function associated with “Menu Option [57]” 334 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Controls 406    -   (e) Hardware Monitor 408    -   (f) Database Module 410    -   (g) Scanning Results Normalization Engine Module 412    -   (h) Reports Module 414    -   (i) Statistics Module 416        Menu Line: [58] Purge old session reports from malware archives        336

Purpose: Selecting the menu option at line [58] 336 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to selectively purge existing session reports from the“Database Module” 410. The code segment associated with “Menu Option[58]” 336 presents the user with a series of check list options thatallow session reports to be search based on type or date. The searchcriteria is passes on to the “Reports Module” 414, which in conjunctionwith the “Database Module” 410 attempts to identify all session reportsthat match the user's search criteria. This matching search criteriacreates a block of responsive session reports that the user can selector deselect. Once selected the “Database Module” 410 is instructed bythe “Reports Module” 414 to permanently delete the selected sessionreports as maintained in the session-table. As always, any problemsencountered during this process are communicated to the user via the“Alerts Module” 404.

When the function associated with “Menu Option [58]” 336 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Alerts Module 404    -   (c) Database Module 410        Menu Line: [59] Compare the infections found in two or more        session reports 338

Purpose: Selecting the menu option at line [59] 338 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsthe user to compare two or more session reports archived in the“Database Module” 410 for similar content concerning infections found.The code segment associated with “Menu Option [59]” 338 presents theuser with a series of check list options that allow session reports tobe search based on type, date, or the name(s) of specific malwareinfections. The search criteria is passed on to the “Reports Module”414, which in conjunction with the “Database Module” 410 attempts toidentify all session reports that match the user's search criteria. Thismatching search criteria creates a block of responsive session reportsspecific to previously discovered infections that the user can select ordeselect. Once selected, the “Database Module” 410 is instructed by the“Reports Module” 414 to compare the content of the selected sessionreports as maintained in the session-table through a series of speciallycrafted database queries. In situations where the sessions are a match,the content of the session-table records are sent to the “ReportsModule” 414 for consolidation into a final summary report. Wherenecessary, the “Reports Module” 414 may engage the “Scanning ResultsNormalization Engine Module” 412 through the services available in the“Master Control Point Dashboard Module” 402 to convert malware vendornaming conventions of infections found into common verbiage specific tothe CVE index. The final version of the report requested is sent to the“Display Control Module” 406 for presentation to the user. If the userhas enabled 3D report capability using “Menu Option [55” 330, allreports are converted to 3D chart formats prior to being sent to the“Display Control Module” 406 and the “Hardware Monitor Display Buffer”408. As always, any problems encountered during this process arecommunicated to the user via the “Alerts Module” 404.

When the function associated with “Menu Option [59]” 338 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Hardware Monitor Display Buffer 408    -   (f) Database Module 410    -   (g) Scanning Results Normalization Engine Module 412    -   (h) Reports Module 414        Menu Line: [60] Based on “findings to date” project likelihood        of more infections 340

Purpose: Selecting the menu option at line [60] 340 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it permitsprojections to be made on the likelihood that additional infections willbe found while examining subsequent forensic images 432 436 from thesame client source. The services offered to the user in this context arethe result of extensive research performed on each and every scanningsession conducted. When the malware scanning engines 712, 714 discover aknown malicious code segment, that information is passed on to the“Statistics Module” 416 which records the data in the hits-table in the“Database Module” 410 as normalized data per the use of services offeredby the “Scanning Results Normalization Engine Module” 412. Thenormalized data available to the “Statistics Module” 416 is constantlyre-analyzed using a series of public and proprietary regressionalgorithms to determine if there is any statistical signifance to thepossibility that “Infection X” may be a predictor of “Infection Y” withrespect to current or future sessions. In cases where there is astatistical signifance the user is advised of same via the “DisplayControl Module” 406. This statistical signifance is then used, based onthe forensic images 432, 436 that still need to be scanned, to predictthe likelihood of discovering additional malicious code infections. Asalways, any problems encountered during this process are communicated tothe user via the “Alerts Module” 404.

When the function associated with “Menu Option [60]” 340 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Alerts Module 404    -   (c) Malware Engine(s) 712, 714    -   (d) Display Control Module 406    -   (e) Database Module 410    -   (f) Scanning Results Normalization Engine Module 412    -   (a) Reports Module 414    -   (g) Statistics Module 416    -   (h) Forensic Image 432, 436        Menu Line: [61] Generate report on suggested mitigation        strategies 342

Purpose: Selecting the menu option at line [61] 342 invokes a codesegment compatible with the “Host Operating System” 400 that is a scriptor executable application programmed in such a manner that it generatesa detailed report on suggested mitigation strategies based on themalicious code infections identified during the current scanningsession. As malicious code infections are discovered they are stored inthe hits-table in the “Database Module” 410 as normalized data per theuse of services offered by the “Scanning Results Normalization EngineModule” 412. After conversion to normalized naming conventions (CVEIndex) is completed the code segment associated with “Menu Option [61]”342 queries the solution-table for suggested mitigation strategies forthis specific infection. The solution-table is a pre-built archive thatis maintained by the “Reports Module” 414 which has the ability, inconjunction with the “Master Control Point Dashboard Module” 402, tocrawl the Internet Web sites of commercial and open source malwarevendors and download/extract all mitigation strategies presentlyrecommended for the malicious code segment under review (hits-table).Note that by default, the “Host Operating System” 400 is configured toblock all Internet and network packets 220 from any form of connectivityas a cyber security measure. If “Menu Option [61]” 342 invoked with theInternet and network blocking enabled, the only suggested mitigationstrategies available for review are those previously created during theinstallation of the present invention (when Internet connectivity isrequired) due to their ubiquitous “in the wild” malware presence. If“Menu Option [61]” 342 invoked by the user with the Internet and networkblocking disabled, the code in this segment will crawl the Internetseeking out recommendations for mitigating the infection justdiscovered. Mitigation strategies discovered during this crawl areautomatically updated to the solution-table. Regardless of the blockingsituation at hand, the “Reports Module” 414 will create a suggestedmitigation report concerning the malicious infection being evaluated byreviewing the content of the solution-table in the “Database Module”410. The mitigation report created will be presented to the user via the“Display Module” 406. As always, any problems encountered during thisprocess are communicated to the user via the “Alerts Module” 404.

When the function associated with “Menu Option [61]” 342 is invoked datain the form of command and control signals will flow between/among thefollowing operational modules as presented in FIG. 13 and FIG. 16:

-   -   (a) Host Operating System 400    -   (b) Master Control Point Dashboard Module 402    -   (c) Alerts Module 404    -   (d) Display Control Module 406    -   (e) Database Module 410    -   (f) Scanning Results Normalization Engine Module 412    -   (g) Reports Module 414

Turning now to the organization diagram of the various modulessupporting the menus/functions described above in FIGS. 6-12 as well asthe modules supporting the flow diagram in FIG. 14 and modules andprocesses of FIGS. 17-21, FIG. 13 shows a primary functional blockdiagram that describes the organization of the various operationalmodules:

Host Operating System 400:

Master Control Point Dashboard Module 402:

Alerts Module 404:

Display Controls 406:

Hardware Monitor 408:

Database Module 410:

Scanning Results Normalization Engine Module 412:

Reports Module 414:

Statistics Module 416:

Malware Engine Selection Module 418:

Deleted Item Recovery Module 420:

Physical Forensic Acquisition Module 422:

Configuration Control Module 424:

Command Line/Graphical User Interface to Malware Engine #1 426:

Command Line/Graphical User Interface to Malware Engine #2 428:

Command Line/Graphical User Interface to Malware Engine #(N+1) 430:

Forensic Image 432:

Temporary storage for deleted items recovered 434:

Forensic image of deleted items recovered on the temporary storagedevice 436:

FIG. 13 is a block diagram that describes the functional aspects of the“Master Control Point Dashboard Module” (MCPDM) 402. At its core theMCPDM 402 constitutes a proprietary software program that has beendesigned to enable the use of the present invention in a manner thatallows for the simultaneous scanning of a single forensic image 432 436of a digital storage device by multiple malware scanning engines 712 714from a single control point. In this case, the single control point isthe MCPDM 402 software program. Each of the components identified inFIG. 13 are secondary subroutines that support the primary softwareprogram designated as the MCPDM 402. Within the primary MCPDM 402software program are 61 user selectable menu options that have beenpreviously described in detail in FIG. 06 through FIG. 12. When the userselects one of the 61 different menu options for execution a series ofsecondary subroutines are called that allows the menu option selected tobe executed in a controlled manner. Overviews of the subroutines calledfor each respective menu option selected are described in detail in theprevious pages. It should be noted that the existence of the varioussubroutines permits an economy of scale to be realized in code design asany action that may be repeated is compartmentalized into a secondarysubroutine, increasing efficiencies and improving quality control. Eachof the block diagram items identified in FIG. 13 are reviewed belowbased on their primary function. A practitioner well skilled in the artwill realize that the overview provided is not a comprehensiveexamination of the code itself, but rather a generalized discussion ofthe functions inherent in each at the pseudo level.

(A) Host Operating System 400 in FIG. 13:

The primary function of the “Host Operating System” 400 is to supportall of the modules identified in FIG. 13 at the operating system level.Each of the entities presented as a block diagram in FIG. 13 aresoftware subroutines that need to communicate with each other and thehost hardware platform 100 components (memory, disk storage, networkconnectivity, peripherals, etc.). The “Host Operating System” 400 ispresented in this context to make it clear that the present invention isnot restricted to usage under any one operating system (Windows, AppleOS, Unix and Linux as well as other proprietary operating systems), butrather is adaptable to any hardware/software system platform capable ofbeing programmed in a manner that satisfies the operational needs thepresent invention.

(B) Master Control Point Dashboard Module 402 in FIG. 13:

The primary function of the “Master Control Point Dashboard Module” 402(MCPDM), which is a software application, is to coordinate, wherenecessary, the activities of all the other modules and provide the userwith a menu driven series of options that integrate all the operationalsteps into a single process capable of achieving the goals of thepresent invention. The MCPDM 402 is, at its core, a menu driven processthat permits the user to sequentially select and apply pre-programmedsteps in an interactive manner in such a way that the present inventionis configured and executed properly. The menu driven process is detailedin FIG. 06 as a selection point for the “Multi-Engine Malware ScanningOptions” array. When the user starts the software application thatcontrols the execution of the present invention the first screen theysee is FIG. 06. This screen allows the user to select from the followingsix menu options:

(1) [TARGET MEDIA] 208: Mount forensic images or devices for scanning(FIG. 07)(2) [RECOVER DELETED] 210: Configure and initiate deleted file recovery(FIG. 08)(3) [MALWARE ENGINE] 212: Select and configure malware engines (FIG. 09)(4) [SCAN CONTROL] 214: Configure/start/stop the scanning process (FIG.10)(5) [MONITOR PROCESS] 216: Real time feedback on malware discovered(FIG. 11)(6) [CREATE REPORTS] 218: Analysis options and detailed results (FIG.12)

These six interactive menu options are under the exclusive control ofthe MCPDM 402. From a software perspective the MCPDM 402 should beconsidered as the “main” structure of the programming code segment whichcan be written in any GUI capable programming language that can passvariables in subroutine calls and be compiled, C++ for example. Theremaining block diagrams of FIG. 13 should be considered as callablevariable passing subroutines with unique features and functions. Whenthe user selects a menu option using one of these six functionalparameters the MCPDM 402 presents another level of menu options (FIG. 07through FIG. 12) that are pre-programmed to satisfy all of theconfiguration and execution parameters necessary to scan the forensicimage 432 of a digital storage device that is suspected of beingcontaminated with malicious code infections with multiple malwarescanning engines 712 714 simultaneously from a master control point—inthis case the master control point is the “Master Control PointDashboard Module” 402. Any interaction the user has with the “scanningprocess” that is the present invention is facilitated by the MCPDM 402.

(C) Alerts Module 404 in FIG. 13:

The primary function of the “Alerts Module” 404 is to maintain adatabase table (notification-table) with the information concerning theuser's preferred preferences concerning the manner in which they desireto be contacted by the “Master Control Point Dashboard Module” 402 andany other modules that need to directly communicate to the user. The“Alerts Module” 404 maintains information on preferred hardwareresources (display types, max. screen resolutions, screen sizes, etc.)as well as preferred contact channels (local console, user accounts,e-mail addresses, identities of file shares, remote access, etc.). Inaddition the “Alerts Module” 404 is programmed to act as an emergencynotification mechanism, alerting the user to the existence of errors andfaults in the scanning process. Every module is pre-configured tocommunicate to the “Alerts Module” 404 by default when an error occursin their respective code segment. The “Alerts Module” 404 is designed tooverride all other functions currently active and present thisnotification to the user directly using their preferred contact process.The errors sent to the “Alerts Module” 404 by other modules are alsologged into a database table (alerts-table) in the “Database Module” 410for future reference. The user can configure the data in thealerts-table by selecting “Menu Option: [38] Configure AlertNotifications” 296, FIG. 10.

(D) Display Control Module 406 in FIG. 13:

The primary function of the “Display Control Module” 406 is to modifyraw data destine for delivery to the “Hardware Monitor Display Buffer”408 in a manner that makes it compatible with the user's displaypreferences. “Menu Option: [44] Select 2D or 3D graphical display foruse in monitoring” 308 provides the user with two options. By default,the 2D option is pre-programmed into the types-table in the “DatabaseModule” 410. All data that is sent to the “Display Control Module” 406by any module is done so in a 2D format. Data sent to the “DisplayControl Module” 406 is typically in the form of charts, graphs and textbased data. If the user has selected 3D as the default then the originaldata needs to be modified to reflect a 3D display format before it canbe displayed properly. The code segment that is the “Display ControlModule” 406 is responsible for making this format modification in nearreal time. The original 2D data or the 3D data, depending on the user'sselection is then sent to the “Hardware Monitor Display Buffer” 408 fordisplay on an appropriate hardware monitor. The software that controlsthe “Display Control Module” 406 is not in the public domain, but ratheris a custom designed code segment specific to the present invention.

(E) Hardware Monitor Display Buffer 408 in FIG. 13:

The primary function of the “Hardware Monitor Display Buffer” 408 is toact as a buffer between the data to be displayed and the hardware deviceselected to display it on. The “Hardware Monitor Display Buffer” 408also has the ability to act as a compatibility interface between the“Host Hardware Platform” 100 and the “Physical Host Operating SystemEnvironment 400 in the form of a DLL driver so that new 3D displays notyet registered with the host operating system can be made to functionwith the present invention.

(F) Database Module 410 in FIG. 13:

The primary function of the “Database Module” 410 is to maintain aseries of database tables that are created during the installation ofthe “Master Control Point Dashboard” 200, 202 software program. The“Database Module” 410 maintains 21 internal database tables with thefollowing names: Default, Error, Feature, Findings, Hardware, Hits,Host, Monitor, Notification, Operations, Refresh, Remaining, Reports,Running, Scan, Session, Severity, Solution, Startup, Types, andWatchdog. Each of these tables is used to store details on current andhistorical events related of the malware scanning process. Initially,after installation a majority of these tables are blank. In other cases,some have been preloaded with operational parameters obtained duringresearch concerning the best configuration to use when executing thepresent invention. Inherent in the software module that is the “DatabaseModule” 410 are subroutine options that allow the user and other modulesto update and modify the content of these tables as required by themalware scanning process. The “Database Module” 410 is the primaryrepository for any data that is later analyzed by the “StatisticsModule” 416, the “Reports Module” 414 and the “Scanning ResultsNormalization Engine Module” 412. The design and implementation of the“Database Module” 410 is not restricted to any particular form ofdatabase construct, rather subroutine calls from other modules to the“Database Module” 410 in the form of SQL queries have been crafted atthe design level to be compatible with any open source or commercialdatabase product available at the time of this writing.

(G) Scanning Results Normalization Engine Module 412 in FIG. 13:

The primary function of the “Scanning Results Normalization EngineModule” 412 is described in detail in FIG. 18. The reader should consultthat overview to its function and purpose. In summary, the “ScanningResults Normalization Engine Module” 412 is a software subroutinedesigned to normalize the naming convention used to identify maliciouscode infections. Typically it is used to query the “Database Module” 410and analyze data in the hits-table to determine if malicious codeinfections that have been found are really a single infection withdifferent Vendor provider names.

(H) Reports Module 414 in FIG. 13:

The primary function of the “Reports Module” 414 is to usepre-programmed templates and ad hoc queries to build reports based onthe data in tables maintained by the “Database Module” 410. Thepre-programmed templates are unique to the present invention in thatthey need to accommodate findings produce by multiple malware scanningengines 712, 714. The process of presenting the results from multiplescanning engines in a single report can be challenging from a logisticalperspective due to the different parameters that need to be reported.The functionality of the “Reports Module” 414 can be called by any othermodule if pre-programmed logic or user intervention is invoked. The“Reports Module” 414 is also programmed with prior knowledge on the besttechniques to use when creating reports that will be viewed in a 3Denvironment. The functionality of the “Reports Module” 414 is alsoclosely linked to the ten menu options available for user selection inFIG. 12. All of these menu options ([53] . . . [61] 326 . . . 342) arefacilitated in one way or the other by the “Reports Module” 414. Thisobservation is especially true with respect to “Menu Option [55] Selecttypes of reports to generate” 330.

(I) Statistics Module 416 in FIG. 13:

The primary function of the “Statistics Module” 416 is to usestatistical algorithms from both the public domain as well asproprietary sources to analyze data maintained in the “Database Module”410 in the form of tables and produce data that can be incorporated bythe “Reports Module” 414 into different types of reports. In addition,the code behind the “Statistics Module” 416 is also capable ofpopulating tables with summary data. An example of this is in “MenuOption: [47] Create statistical projections on time to completescanning” 314, where the “Statistics Module” 416 is responsible formonitoring current scanning activities and creating an estimate time tocompletion for all scanning engines currently in use.

(J) Malware Engine Selection Module 418 in FIG. 13:

The primary function of the “Malware Engine Selection Module” 418 is toact as a gatekeeper between the “Master Control Point Dashboard Module”402 and each occurrence of the “Command Line/Graphical User Interface toMalware Engine #X” 426 . . . 430 and its associated “Instances Of TheVirtual Operating System” 704, which supports an individual instance ofa unique malware scanning engine 712. Access to each individual malwarescanning process is enabled or disabled based on the user's selectionsmade via “Menu Option [25]: Select malware engine(s) to be used inscanning process” 270. The gateway function also exists as a mechanismthat allows other modules, with the assistance of the “Master ControlPoint Dashboard Module” 402 to tap into the data flow originating fromthe “Malware Engine Selection Module” 418 as well as data flowing to itfrom other modules. For example, the “Statistics Module” 416 collectsreal time data from the malware scanning engine 712, analyzes it andupdates a variety of tables in the “Database Module” 410. It does thisby monitoring data flowing in and out of the “Malware Engine SelectionModule” 418. As mentioned previously, modules such as the “MalwareEngine Selection Module” 418 are really subroutines in a softwareprogram that are capable of passing variables among and between othersubroutines/modules. This variable passing is at the heart of the designgoal of data sharing and collection.

(K) Deleted Item Recovery Module 420 in FIG. 13:

The primary function of the “Deleted Item Recovery Module” 420 is toanalyze the content of the forensic image 432 provided for malwarescanning and determine if there are any deleted items in “free space”that can be recovered for malicious code scanning. To be successful,this process needs to be implemented in a structured manner. Tofacilitate that understanding at a greater level a separate figure, FIG.15 was created, along with a detailed description (see paragraph [1386])of this process. Further clarification on this process and how itcommunicates to other modules can be obtained by reviewing FIG. 15.

(L) Physical Forensic Acquisition Module 422 in FIG. 13:

The primary function of the “Physical Forensic Acquisition Module” 422is to assist the user in forensically acquiring the entire content of adigital storage device suspected of being infected with a malicious codesegment. FIG. 07 provides a list of the different steps that must befollowed to ensure that the creation of a forensic image meets industrybest practices. The acquisition and creation of a duplicate forensicimage 432 is an extremely well documented process within the forensiccommunity. Its functionality in FIG. 13 is provided solely as areference to explain where the data to be scanned by the malwarescanning engines came from. One skilled in the art of forensicacquisition will readily realize the process of image acquisition is inthe public domain and not one the present invention could claim as aunique feature of the proposed embodiment. It should be noted here thatthe “Physical Forensic Acquisition Module” 422 and its initial processsteps can be partially bypassed if the client provides the data to bescanned for infections in a forensic format such as E01 or raw DD, asopposed to raw binary data on a digital storage device.

(M) Configuration Control Module 424 in FIG. 13:

The primary function of the “Configuration Control Module” 424 pivots onmaintaining operational data on current and past configurations in amanner that allows operational parameters to be applied and adjusted inthe most efficient method possible. One of the unique characteristics ofthe present invention is its ability to select one or more malwarescanning engines 712 714 to be active at the same time in a simultaneousscan. As more or less malware scanning engines 712 714 are added to theprocess the demands on hardware and software resources concerning therunning of the “Virtual Support Environment” 702 and each “Instance OfThe Virtual Operating System” 704 and the individual “Malware ScanningEngine” 714, 714 change significantly. In some cases these hardware andsoftware resources can be adjusted on-the-fly to accommodate enhancedlevels of performance. This is one of the goals of the “ConfigurationControl Module” 424. The “Configuration Control Module” 424 is designedto constantly query the “Database Module” 410 and examine the content ofall tables that contain any form of performance data. For example, thestartup-table, the hardware-table and the session-table offer insightinto the performance of the process. The “Configuration Control Module”424 is designed to compare existing performance factors with historicalratings based on the number of malware scanning engines in operation.When it finds evidence that increased performance factors may bepossible by using historical settings it attempts to reconfigure thelocal environment to that configuration. All of this is done in thebackground without any input from the user. In addition, the“Configuration Control Module” 424 monitors the configuration parametersof the forensic image 432 to ensure that it is configured to be in theoptimal read state. The forensic image being scanned for malicious codesegments is by default a read-only file. As a result, it is beneficialto confirm that its folder location within the “Physical Host OperatingSystem” 400 is configured for optimum read access as opposed toread/write access. The “Configuration Control Module” 424 takes on theresponsibility of making sure this option is confirmed. TheConfiguration Control Module” 424 also plays a critical role inassisting other modules and menu options in their execution. Forexample, “Menu Option: [24] Select malware engine applications &signatures for updating” 268 is critical to the successful operation ofthe present invention. Without the assistance of the ConfigurationControl Module” 424 in being able to advise on the current version levelof virus based signatures, this menu option would fail due to incompleteinformation.

(N) Command Line/Graphical User Interface to Malware Engine #1 426 inFIG. 13:

The primary function of the “Command Line/Graphical User Interface toMalware Engine #1” 426 is to play the role of middle-man in providing acommunications channel between the “Master Control Point DashboardModule” 402 and the “Instances Of The Virtual Operating System” 704, aswell as the unique “Malware Scanning Engine” 712 supported by thisvirtual operating system environment. The purpose of this interface isto allow the “Master Control Point Dashboard Module” 402 to use commandline based scripts to execute different functions in the “Instances OfThe Virtual Operating System” 704 selected by the user or issue systemcalls to the Graphical User Interface associated with the “Instances OfThe Virtual Operating System” 704. In both cases the end result is thatvarious forms of specific commands can originate from the “MasterControl Point Dashboard Module” 402 and be received by either the“Instances Of The Virtual Operating System” 704 or the unique “MalwareScanning Engine” 712 previously selected by the user and executed as ifthe command/GUI call was executed locally. An example of thisfunctionality is associated with “Menu Option [39]: Start malwarescanning engine(s)” 298 where the user selects a menu item in FIG. 10from a list of nine available options that when properly conveyed fromthe “Master Control Point Dashboard Module” 402 to the selected MalwareScanning Engine 712 will start the process that is the present inventionby sending a “GO” command as previously discussed in the overview of“Menu Option [39]: Start malware scanning engine(s)” 298. It should benoted that FIG. 13 has redundant blocks that all serve the samefunction. Those redundant blocks, identified as 426, 428 and 430 havebeen provided to demonstrate the embodiment of the present invention,which is that multiple malware scanning engines 712, 714 can be enabledsimultaneously for the purpose of scanning a single forensic image formalicious code segments. While these blocks are redundant in functionthey are unique in that each supports a dedicated communication channelto a unique malware scanning engine 712. As a result of this redundancy,the following two block diagram items are not described as theirfunction and purpose is identical to this description.

(O) Command Line/Graphical User Interface to Malware Engine #2 428 inFIG. 13:

The “Command Line/Graphical User Interface to Malware Engine #2” 428block item presented here is identical in function and purpose to blockdiagram item 426 above. As a result it is not detailed here.

(P) Command Line/Graphical User Interface to Malware Engine #(N+1) 430in FIG.

The “Command Line/Graphical User Interface to Malware Engine #(N+1)” 430block item presented here is identical in function and purpose to blockdiagram item 426 above. As a result it is not detailed here.

(Q) Forensic Image 432 in FIG. 13:

The primary function of the “Forensic Image” 432 is to provide an E01read-only image of a digital storage device for malware scanning.Forensic images are unique on two fronts. First, they can be abit-by-bit, sector-by-sector duplicate image of all valid and deletedfiles on a digital storage device, or they can be file level copies ofvalid files only. Second, E01 images are created with embedded hashdigest information and can be used to verify the integrity of the dataat any later point in time. In addition, E01 images can be embedded withdata concerning the date and time the image was created, who created it,who provided it for analysis as well as the name of the individualcreating the forensic image. The concept of a forensic image is criticalto the execution of the present invention in that its functionality isdependent upon the availability of an E01 forensic image to scan. Thiscritical status is a function of the read-only parameters associatedwith the design of the E01 forensic image. Being read-only allowsmultiple malware scanning engines to scan its content without having theability to modify its content. This is important in that every opensource and commercial malware solution will attempt to automatically“clean” any malicious infections found. In doing so they attempt tomodify the original data. If this was permitted then subsequent scans bydifferent malware engines would not find this particular malicious codesegment. The default, read-only status of the E01 image resolves thissituation making its use a unique feature of the present invention. Theinteraction of the “Forensic Image” 432 with other components of thepresent invention is detailed in FIG. 17, the “Malicious Code DiscoveryModule 716. This figure should be reviewed as a means of getting abetter understanding of the embodiment of the present invention.

(R) Temporary Storage for Deleted Items Recovered 434 in FIG. 13:

The primary function of the “Temporary storage for deleted itemsrecovered” 434 is to facilitate the recovery of deleted items from theprimary forensic image 432. The functionality of this public domainprocess is described in FIG. 15 in detail. This figure should bereviewed as a means of getting a better understanding of the embodimentof the present invention with respect to this function.

(S) Forensic Image of Deleted Items Recovered on the Temp. StorageDevice 436

The primary function of the “Forensic image of deleted items recoveredon temp. storage device” 436 is to provide a read-only forensic imageversion of the deleted items found on the forensic image 432. Thefunctionality of this public domain process is described in FIG. 15 indetail. This figure should be reviewed as a means of getting a betterunderstanding of the embodiment of the present invention with respect tothis function.

FIG. 14 is a exemplary high level overview flowchart summarizing theabove described functions for the operation of the present system, FIG.14 where a user scans a forensic image using the multi-engine malwarescanning of the present invention.

At step 500, a user obtains target storage device and generates aduplicate forensic image to be subject to multi-engine malware scanning.Such a process is described in detail above with respect to FIGS. 3-5and 7 and the associated descriptions outlining the various user optionsregarding the forensic image creation. At step 502, the user thengenerates a second set of data, if applicable, to be subject tomulti-engine malware scanning by recovering certain deleted items asoutlined in detail above in FIG. 8 and the related descriptions.

At step 504, once the two data sets are ready (forensic image andrecovered deleted items) the malware engines of the present system arerun against those data sets as outlined in FIG. 9 and the relateddescriptions. At this stage the multi-engine malware scanningarrangements are initially configured according to the user'sspecifications. At step 506, various scan control options are offered bythe system and/or utilized by the user as outlined above in FIG. 10 andthe associated descriptions. It is at this stage that the multi-enginemalware scanning is applied in parallel against the desired forensicdata sets. During the scanning process, at step 508 the user mayconfigure the various monitoring options as outlined in detail above inFIG. 11 and the related descriptions.

Finally, once the various multi-engine malware scanning is appliedagainst the desired forensic data sets and completed, various reportsfrom the difference malware scans are generated and complied as setforth in detail in FIG. 12 and the related description.

Having listed and described the various hardware, and software modulesof the present system as well as the overview and detailed flowdescriptions of the operation of the multi-engine malware scanningprocess, the following descriptions, provide additional detailsregarding the various aspects of the invention.

For example, FIG. 15 is a detailed block diagram of the “Deleted ItemRecovery Module” 700 (DIRM). This diagram illustrates the hardware andsoftware components required to recover deleted files from a forensicimage 432, 436 as outlined above for example in FIG. 8 and the relateddescription. This function represents an additional feature of thepresent invention in that none of the prior art associated with virusand malware scanning attempts to examine deleted file space, oftenreferred to as “free space,” for evidence of malicious code infectionsthat may have been deleted by hackers, directly or indirectly, in aneffort to cover their tracks after compromising a computer system. Note:The actual recovery of deleted items from the duplicate forensic image432 of a digital storage device is not a unique feature of the presentinvention as this technology driving this process is in the publicdomain (See previous discussion concerning FIG. 08, “Menu Option [20]”260). Rather what is unique is the recovery of deleted items for thesole purpose of including their content in the scanning for maliciouscode infections.

The “Deleted Item Recovery Module” 700 detailed in FIG. 15 includesthree basic hardware and software support components: a “Host HardwarePlatform” 100, as described in FIGS. 01 and 02, a “Physical HostOperating System Environment” (Microsoft's Server 2012, Microsoft'sWindows 7 Ultimate or 8.1 Pro) 400, and a “Virtual Support Environment”(VMWare or Hyper-V) 702. These three hardware and software componentsform the core structure that supports the embodiment of the presentinvention as it relates to deleted item recovery. For ease ofillustration and because they are not relevant to an understanding ofthe present invention, FIG. 15 does not show the typical peripheralsassociated with a computing device 100 such as a hardware display,keyboard, mouse, printer, or other I/O devices. The “Virtual SupportEnvironment” 702 supports multiple “Instance Of The Virtual OperatingSystem” 704 (VOS) which with respect to the initial deployment of thepresent invention may be Windows 7 Professional or other comparableoperating systems.

Applicants note that the “Instances Of The Virtual Operating Systems”704 (VOS) depicted in FIG. 15 came into existence as a result of effortsto expand the efficiencies of previous investments made in computerhardware and software. Prior to VOS the rule was that a single computersystem could only host a single operating system. In these situations, asingle computer system was typically dedicated to a single function suchas but not limited to: e-mail, file sharing, backup and securitycontrols. This operational mandate created vast levels of inefficienciesas systems dedicated to single functions were vastly underutilized withrespect to CPU processing cycles and hard drive storage utilization.Economies of scale were not being realized.

However, software developers skilled in designing operating systemsrealized that this wasted computing power could be harnessed andmanipulated so that a single computer system could host multiplededicated functions, as opposed to just one. This improvement incomputer utilization resulted in an environment where a singleunderutilized computer system could be segmented into multiple “virtual”worlds. Each virtual world 704 was an instance of a single operatingsystem co-existing with, but independent of all other virtual worlds.This segmented isolation resulted in a solution where a single physicalcomputer system could be configured (using virtual software such asVMWare or Hyper-V) to have the functionality of multiple independentcomputer systems. The design philosophy of virtual technology resultedin economies of scale being realized.

The benefits of such VOS virtual technology are used in the presentinvention as it allows multiple instances of different malware scanningengines 712, 714 to co-exist on a single physical computer system 100, afeat that would have been impossible prior to the introduction ofvirtual technology. Having the ability to configure a single physicalcomputer system as a Host Hardware Platform 100, as presented in FIG.15, to support multiple versions of different virtual operating systems704, each supporting their own unique combination of different softwareapplications creates an environment where significant efficiencies arerealized and costs contained. One such example of this capability is theuse of an instance of a VOS 704 to host the forensic applicationsoftware 706 that includes a “Deleted Item Recovery Module” 420 which iscapable of recovering deleted items from the forensic image 432 of astorage device suspected of being compromised with malicious codeinfections.

In the present invention, the VOS 704 identified as shown in FIG. 15hosts a “Forensic Analysis Software” 706 (FAS) application. Threeexamples of commercially available Forensic Analysis Softwareapplications are: X-Ways Forensics (X-Ways Software Technology AG),EnCase (Guidance Software) and FTK Toolkit (AccessData Group). The FAS,which can be either a commercial or open source program, will have aninternal “Deleted Item Recovery Module” 420 (DIRM) capable of recoveringdeleted items from the free space of a forensic image 432. Itemsrecovered by the DIRM 420 are written to a “Recovered Items” 434 storagerepository for additional processing. The additional processing includesconverting the items recovered into a forensic image 436 so that theseitems can be scanned by the malware engines 712 714. The DIRM 420utilizes a dedicated hard drive 434 with sufficient storage capacity tohold copies of all deleted items recovered from the forensic image 432.The hard drive 434 utilized by the DIRM 420 for temporary storage isreplaced with a new blank hard drive as required or the drive iscompletely wiped to military specifications using commercial tools priorto reuse.

The “Deleted Item Recovery Environment” 700 outlined in FIG. 15 is onethat can be launched using the “Master Control Point Dashboard Module”200 using the “Recover Deleted” 210 menu options, specifically “MenuOption [20]” 260: “Start deleted item recovery process.” In all cases,the methods used to launch this process and recover the deleted items toa storage repository 434 have been specifically created to support thepresent invention.

The present invention is unique with respect to two related functions.The first related function is the ability to scan one or more forensicimages 432 with multiple malware scanning engines 712, 714simultaneously from a master control point 402 for malicious codeinfections. The second related function, as described in FIG. 15, is theability to examine the forensic image 432 for deleted items in “freespace” and recover those items to a temporary storage device 434. Forease of illustration and because they are not relevant to anunderstanding of the present invention, specific technical detailsconcerning the forensic software techniques used to recover deleteditems from free space are not included in this application as they arein the public domain. Once the deleted item recovery process iscompleted, using the functionality of the “Deleted Item Recovery Module”420, all items recovered 434 are converted into a forensic image 436that can be examined by the malware scanning engines 712, 714 formalicious code infections.

The functions described in FIG. 15 along with the hardware and softwarerequired to support these functions represents the initial embodiment ofthe present invention with respect to one of the two primary inputs(deleted items and a forensic image) required by the process of thesystem. For ease of illustration and because they are not relevant to anunderstanding of the present invention, specific technical detailsconcerning the forensic software techniques used to recover deleteditems from free space are not included in this application.

FIG. 16, “Malware Scanning Engine Platform Module” 708, in furtheranceof the descriptions above, is a more detailed block diagram thatillustrates the process and arrangement whereby a single physical hosthardware platform 100 can be configured to support multiple virtualoperating system environments 704, each capable of scanning(simultaneously) a forensic image 432, 436 with a different malwareengine 712, 714. “Malware Scanning Engine Platform Module” 708 asdepicted in FIG. 16 is a full and complete embodiment of the virtualaspects of the present invention. The hardware and software environmentdetailed in FIG. 16, with respect to the “Host Hardware Platform” 100,the “Physical Host Operating System Environment” 400, and the VirtualSupport Environment 702 are all located on the same physical computingdevice. These core components are described here for clarity purposesonly and this description is not meant to infer that more than onephysical computer system is required to support the system and method ofthe present invention. It should be noted that the core componentsthemselves are not unique aspects of the present invention; rather theyare support components that enable the present invention to function ina manner that makes it a unique method that is capable of scanning forevery known malicious code infection.

FIG. 16 identifies a critical aspect of the present invention—that beingthe ability to stand-up repeated instances of the Windows operatingsystem in multiple “Instance Of The Virtual Operating System” 704 shellson a single physical computer system 100 using a virtual supportenvironment 702 that is designed to be capable of scanning a forensicimage 432 436 FIG. 17 with multiple malware scanning engines 712 714simultaneously.

Creating a working virtual environment 708 as depicted in FIG. 16 is notdifficult and well within the capabilities of a typical user who haspast experiences that involved formatting a hard drive and installing anoperating system capable of booting the physical computer to a userprompt. One example (of many) in creating a “Virtual SupportEnvironment” 702 capable of supporting multiple “Instances Of TheVirtual Operating System” 704 that each have a different “MalwareScanning Engine” 712, 714 installed consists of the following steps:

-   (a) Purchase a high-end physical computer system running Windows 7    Ultimate 100.-   (b) Purchase a licensed copy of the VMWare Workstation software.    (See e.g. http://www.vmware.com/products/workstation/ 702.)-   (c) Perform a standard install of the VMWare Workstation software.    (See e.g. User Guide:    http://www.vmware.com/support/pubs/ws_pubs.html 702.)-   (d) Purchase an additional licensed copy of Windows 7 Professional    704.-   (e) Purchase/obtain a licensed/free copy of a malware scanning    engine 712.-   (f) Execute and run the VMWare Workstation software 702.-   (g) Create a virtual operating system shell using the VMWare    Workstation software 704.-   (h) Format the virtual operating system shell with the Microsoft    NTFS file system 704.-   (i) Install the copy of the Windows 7 Professional operating systems    purchased in step (d) into the formatted virtual operating system    shell 704.-   (j) Finish the installation of the Windows 7 operating system by    updating to the most current service packs and patches 704.-   (k) Install additional software applications as required. With    respect to the present invention this would at the minimum include    but not be limited to:-   (1) An instance of a malware scanning engine 712, 714.-   (2) Commercial software capable of mounting a forensic (E01, dd,    etc.) image 432 created from a hard drive suspected of being    infected as a logical device. For example: FTK Imager (See e.g. User    Guide:    http://marketing.accessdata.com/acton/attachment/4390/f-000d/1/-/-/-/-/file.pdf    718)-   (3) Commercial software designed to perform complete or partial    screen captures of data displayed on the desktop (for reports and    affidavits where necessary).-   (4) Commercial forensic analysis and deleted file recovery software    such as but not limited to: X-Ways Forensics, EnCase and the FTK    Toolkit 420.-   (5) An open source or commercial text editor.-   (6) Commercial or open source software designed to control the    actions of the instances of VMWare or Hyper-V created by this    process in the form of internal or external scripts capable of    communicating back to the “Master Control Point Dashboard Module”    402.

The above process, starting with step (d), can be repeated as many timesas technically feasible given the operational limitations of thehardware purchased in step (a). As the process is repeated additionalinstances of a Windows operating system environment are created, eachbeing capable of hosting a different malware scanning engine 712, 714.Each of these different instances are unique in that they co-existindependently of each other but as designed have two common externaloperational areas each can access simultaneously. The first common areais where the forensic images 432, 436 are stored. The second common areais an isolated folder on the host operating system 400 that is used bythe “Master Control Point Dashboard Module” 402 to control theoperations, via scripts and executable programs, of the softwareinstalled in each virtual instances created.

The first common area allows all of the virtual worlds created (step (a)through step (k) above) to have read-only access to the same forensicimages suspected of being infected 432, 436. Having an environment wherea single forensic image 432, 436 can be scanned simultaneously bymultiple malware engines 712, 714 increases scanning efficiencies byfactors. It is estimated that this increased efficiency could reducescanning times from 200 sequential hours total, to just under five. Thisgain in efficiencies is one of the primary benefits of the presentinvention.

The second common area includes storage for the “Database Module” 410which permits all the virtual worlds created, and the software installedin each, to be controlled by a script driven environment that isrealized in the form of a dashboard display 402 on the desktop withoperational controls designed to manipulate each and every instance ofthe virtual worlds created. This dashboard is a visual projection of thefunctions of a master control point detailed at the conceptual level inFIG. 06 and discussed in detail previously starting with paragraph[1128].

The master control point dashboard 402 and its corresponding displaycontrols module 406 are a series of stand-alone executables designed bysoftware developers at the request of the authors of this presentinvention. This executable application 402 is designed to be installedon the physical computer system hosting the virtual worlds created inthe steps detailed above. The master control point is a collection ofscript driven functions designed to manage the entire process ofscanning a forensic image with multiple instances of different malwareengines simultaneously using virtual instances 702 of the Windowsoperating system. An example of some of the operational functionsavailable under the umbrella of the master control point and itsassociated dashboard display are detail in FIG. 06. As previouslydescribed, the operational and management menu functions it provides theuser as selections described in FIG. 13 reflect the core components thatneed to be controlled to ensure that all E01 forensic images are scannedin a manner that guarantees the discovery and identification ofmalicious code segments.

The functional aspects of the components in FIG. 16 establish that a“Malware Scanning Engine Platform Module” 710 can be configured andimplemented multiple times over in the combined form of “Instances OfThe Virtual Operating System” (VOS) 704 and a “Malware Scanning Engine”(MVSE) 712 714. Each VOS 704 is unique in that each hosts a different“Malware Scanning Engine” 712 714 capable of scanning a duplicateforensic image for malicious code. This exemplary embodiment can host atleast 32 different malware scanning engines 712, 714 in this virtualenvironment 710.

The operational aspects of FIG. 16 are tied directly to the “MasterControl Point Dashboard Module” 402 through the “Command Line/GraphicalUser Interface to Malware Engine #X” 426 . . . 430. As mentionedpreviously, the dashboard module 402 is a collection of programmingsubroutines designed to communicate with the other modules usingembedded variables that are passed between and among the other modulesdepicted in FIG. 13. For example, the “Statistics Module” 416 in FIG. 13can communicate with one of the malware scanning engines 412, 417 bysending it an embedded variable which contains a script, which whenexecuted instructs the malware scanning engine to report the name of thelast infection it found. This data is captured by the script and sentback to the “Statistics Module” 416 for additional analysis as anembedded data variable in a subroutine return.

As previously identified, the master control point is a collection ofscripts and executable programs designed to communicate electronicallywith each instance of the virtual operating system worlds created. Theuser interface for the master control point is a dashboard display thatacts as a front-end to the technical parameters that drive the operationof each operating system instance as detailed in FIG. 06. Theinteractive dashboard display permits the user to locally or remotelyactivate or deactivate explicit functions within each virtual operatingsystem environment, especially with respect to the operation of themalware engines. In addition to controlling the key operational aspectsof each virtual operating system 710 the master control point dashboardconstantly monitors 216 the progress and status of all relevantfunctions both in real time as well as from historical logs maintainedby each virtual operating system environment. The data exchanged betweenthe master control point and all the instances of virtual operatingsystems running are normalized, per FIG. 18 described below, andpresented in a form compatible with the default dashboard display 406408. The interactive dashboard display 402 then becomes the primaryinterface between the administrator and the instances of multiplevirtual operating systems created 704 and enabled by the use of thevirtual environment's software management application.

While the “Master Control Point Dashboard Module” 402 is a primarycomponent of the present invention it should be obvious to allexperienced in the art that this approach is but one of many means bywhich the functions inherent in the “Master Control Point DashboardModule” 402 can be controlled and monitored. It is understood that thepresent arrangement is intended to include any and all scenarios,regardless if they are hardware or software when describing a userinterface that permits various operational functions to be controlled,either locally or remotely, with respect to the “Instances Of virtualoperating systems 704 hosted under the Virtual Operating Systems” 704and the “Malware Scanning Engines” 712, 714 they host.

The block diagrams presented in FIG. 17 represents certain operationalcapabilities created by the present invention. FIG. 17 helps illustratethe interplay of various unique aspects of this present invention. Thisfigure, further described as the “Malicious Code Discovery Module” 716.This figure encompasses a vast majority of the unique aspects of thepresent invention. This figure outlines the two primary inputs requiredfor scanning to occur, which include a forensic image 432 of valid filesand a forensic image of deleted/recovered items 436. In addition to theforensic images, there are three other operational modules 412, 416, 402which help create output for the system. These are the “Master ControlPoint Dashboard Module” 402, the “Statistics Module” 416 and the“Scanning Results Normalization Engine Module” 412. A key characteristicof the present invention is its ability to have different malwarescanning engines 712, 714 installed in multiple “Instances Of TheVirtual Operating Systems” 704 so that multiple malware scans can belaunched simultaneously against the same duplicate forensic image 432and its corresponding forensic image of deleted items 436. Access to theduplicate forensic image(s) is facilitated by a “Logical DriveInterface” 718, 720, a software program in the public domain thatenables the Microsoft Operating System to access the duplicate forensicimage as a physical or logically attached device.

An example of the “Logical Drive Interface” 718, 720 is the executableapplication “FTK Imager” by the AccessData Group. Its primary function,with respect to the present invention, is to transform the data found ina forensic image 432 so it appears to the Windows operating systemenvironment as a mountable logical storage drive (e.g.; D:\, E:\, etc.).Once mounted in such a manner the storage drive is accessible to othersoftware programs in read-only mode. In this case, the other softwareprogram would be a unique version of a commercial or open source malwarescanning engine 712, 714 installed in a exclusive instance of thevirtual shell 704. In normal operation, communications from the “MasterControl Point Dashboard Module” 402, at the direction of an appropriatemenu option selected by the user, for example “Menu Option [06]: MountSelected Partition(s) as Logical Device(s)” 232 would instruct aspecific virtual operating system instance 704 to enable the “LogicalDrive(s) Interface” 718, 720 (in this example the local copy of FTKImager) and launch it as a process within the virtual operating systemselected. The virtual operating system instance 704 would thencommunicate back to the “Master Control Point Dashboard Module” 402using text based protocols advising that the instructions had or had notbeen accomplished successfully. Once launched, the FTK Imagerapplication, at the direction of user actions initiated via the menuoptions, would select and mount a forensic image and make it accessibleas a logical drive (e.g.; D:\, E:\, etc.) under the Windows operatingsystem. Such actions would originate from the user's selection of “MenuOption [05]: Assign logical identifiers to mounted partition(s) (E:\.F:\, etc.)” 230.

This process of initiated action, feedback and ongoing monitoring of theinvolved services and processes, using the “Master Control PointDashboard Module” 402 and the behind the scene master control pointscripts and database tables, would be continued for all the stepsnecessary to scan the selected forensic image for malicious codeinfections. As each step was initiated and completed those statuseswould be updated on the dashboard display 406, 408 in real time by the“Alerts Module” 404 as data sent to the “Display Controls Module” 406.

FIG. 18 presents details on a custom designed process that is unique tothe present invention and engines 412, 402, 416 associated with thissystem and the scanning method it proposes. The “Scanning ResultNormalization Engine Module (SRNE)” 412, FIG. 13 is series of scripts,C++ code segments and database tables in the “Database Module” 410 thathave been created to take vendor specific data 722 produced by themalware scanning engines 712, 714 concerning infections found andaggregate all the data into a single normalized data structure 724 in anaccessible database table format. An example of the function availablethrough the SRNE 412 is provided in FIG. 18.

The SRNE 412 process, as detailed in FIG. 18 is a custom built softwareanalysis program designed to normalize the many different names a singlevirus may have 722 across all the malware detection vendors in thismarket space. For example, while two different commercial malwareengines may be able to locate the same virus 722 (based on a common hexbased signature string), both may identify it based on their own uniquenaming convention. The SNRE 412 was created as a management basedutility to prevent a single virus from being identified as two separateand unique viruses. The SNRE 412 accomplishes this goal by reducing thenaming variability, where possible, to a single known malware signaturecataloged by the Common Vulnerabilities and Exposure (CVE) index or databases with similar functions and purpose.

In normal operation, the SRNE 412 application, depicted in FIG. 18,would act as an access point for the “Database Module” 410 maintained bythe “Master Control Point Dashboard Module” 402, which is a table drivenrepository of all of the infection reports generated (hits-table) by theindividual “Malware Scanning Engines” 712, 714 install in each instanceof the virtual operating systems 704 put in place. These reports wouldbe obtained from each individual malware scanning engine. A customscript/program associated with the “Master Control Point DashboardModule” 402 (for example, “Menu Option [49]: Display count of maliciouscode instances found so far” 318) would target the malware scanningengine of interest by setting up a text based communication channelbetween the “Master Control Point Dashboard Module” 402 and therespective “Instance Of The Virtual Operating System” 704. Onceestablished, the custom script/program would initiate actions within themalware scanning engine 712, 714 for the purposes of having it generatea local text based report on any recent malicious code infectionsdiscovered. This local report would then be automatically forwarded tothe SRNE 412 application for normalization. The raw un-normalized data,along with the normalized data, would be available for inspection andreview by any user with access to the “Master Control Point DashboardModule” 402. In cases where the individual malware scanning engine didnot have the ability to produce a text based report of its findings, anadditional custom script/program would be executed. This customscript/program would have the ability to perform a “screen scraping” ofthe graphic based report produced by the malware scanning engine 712,714. The screen scraping function would convert the graphical based datainto text based data and forward that data on to the SRNE 412application for normalization.

While the process defined in FIG. 18 is detailed and involved, it is, atthe conceptual level nothing more or less than a compilation of theactions a typical user would take who has multiple computers, each witha different malware scanning engine installed. Configuring eachrespective malware scanning engine 712, 714 to scan the digital storagedevices attached to the computer systems, and then collecting theresults produced in a database 410 for analysis is the core basis of thepresent invention. Except in the case of the present invention, themalware scanning is performed simultaneously, by 32+ malware scanningengines 712, 714, on a single forensic image 432,436 of a suspected harddrive deemed to be infected.

The block diagram presented in FIG. 18, along with the custom scriptsand table queries the “Master Control Point Dashboard Module” 202(MCPDM) detailed in FIG. 06 is series of scripts and programs created toprovide functional control over all available malware applicationsenabled by this present invention. The MCPDM also has the ability tointegrate with the SRNE 412 so that normalized data can be accessed forthe purpose of providing operational updates, reports 414 andstatistical projections 416 on the impact to the organization of anymalicious code discovered. Examples of the functions available under theMCPDM can be found in FIG. 06.

In all cases, the custom scripts and programs developed to facilitatethis and other control and monitoring functions are based on asimplistic text-based protocol where data in a “Database Module” 410 isexchanged and updated in “custom activity tables” unique to eachinstance of the “Virtual Operating System” 704 enabled under the“Virtual Support Environment” 702. These tables are updated in real-timeby custom scripts/queries running under each individual “VirtualOperating System” 704 enabled. All tables associated with the “DatabaseModule” 410 are located in a common area to which each respective“Virtual Operating System” 704 has access. This common area wouldtypically be a folder on the hard drive of the “Physical Host OperatingSystem Environment” 400 hosting the aforementioned environment. Thiscommon database area is designed to enable the individual virtualoperating systems 704 to communicate with the MCPDM scripts/queries (andvice-versa) so that real-time data can be obtained for the purpose ofrefreshing the “Display Module” 406 with current data. In addition toreal-time data updates provided by the applications and scripts runninginside each virtual operating system 704, these communication channelscan also be used to pass commands and instructions (as well asresults/errors encountered) from the MCPDM to the individual instancesof the virtual operating systems 704 and the services/processes theyeach host internally.

Lastly, with respect to “Statistical Projection Analysis Engine (SPAE)416 (FIG. 13), the SPAE capitalizes on the fact that data gathered frommultiple malware scanning engines offers a unique opportunity forextrapolation not currently offered by any commercial or open-sourcevendor security solution. The primary purpose of the SPAE is to allowresearch to be performed for the purpose of identifying unknown exploitsbased on the findings generated by the 32+ scanning engines the presentinvention is capable of launching against a set of forensic images.

FIG. 19 is a block diagram that further illustrates details regardinghow certain functions of the present invention could be managed in analternative manner that, despite limitations, could accomplish theprimary goal of scanning a single forensic image 432, 436 with multiplemalware engines simultaneously 712, 714. As with the preceding examples,a forensic image 432, 436 is created by a forensic technician of thehard drive that needs to be scanned for malware infections. That harddrive, containing the forensic image of the system to be scanned, isthen manually configured for duplication by the forensic technician andreplicated using a commercial one-to-many hard drive duplicator 732.

In FIG. 19, this device is shown to have 25 slots 734. One slot is forthe source device to be duplicated and the remaining 24 slots are filledwith blank hard drives. This configuration allows for a maximum of 24separate duplicate images to be created simultaneously (in this case,quantities may vary based on the type of commercial hardware duplicatorutilized). Once the duplicate hard drive images are created they arephysically transported 736 by the forensic technician to a commercialhardware hard drive docking station 730 that is attached to a commerciallaptop or desktop 726, 728. In this representation of the presentinvention each laptop or desktop 726, 728 has a different malware engine712, 714 installed on the computer system 726, 728 as a functioningsecurity control. The number of laptops/desktops 726, 728 in use at anyone period in time is based on the number of different malware scanningengines 712, 714 required for the scanning task at hand. The results ofeach malware scan run are then either collected manually or written to acommon database repository by a series of scripts or specializedapplications authored specifically for this purpose.

The block diagram in FIG. 20 details an alternative embodiment with thepresent invention's method implemented in a network environment. Whilethe hardware delivery system detailed in this figure is different thanprevious figures discussed, the method is not. In this example, thepresent invention's method (scan one forensic image with multiplemalicious code detection engines simultaneously) is duplicated such thatmanual or automated (script/program driven) functions can be applied tothe hosted environment. In this situation, the forensic images of thehard drive 432, 434, 436 to be scanned for instances of maliciousinfections are made accessible by mounting same on a computer system 762hosting the image in question. This computer system is connected to anetwork hub or switch 758 using either hardwired or wirelessconnectivity 760. Connected to the hub or switch are multiple computersystems 740, 742, 746 and 748 that are configured using hardwired orwireless techniques 750, 752, 754 and 756. Each of these computersystems 740, 742, 746 and 748 are individually configured to host adifferent malicious code detection scanning engine. The total number ofcomputers (N+1) 748 running a different malicious code detectionscanning engine are a function of local resources and internal networkbandwidth. Each of the scanning engines/computers are controlled byeither manual of automated processes from a master control point. In allcases the hosting network environment is configured so that permissionsexist so that the scanning computer systems 740, 742, 746 and 748 havedirect remote access to the forensic image 432, 436 that has beenphysically and logically mounted on the Image Host 762 computer system.

The block diagram in FIG. 21 mimics the functionality of FIG. 20 withthe difference being that either a private or public cloud environmentis used as a replacement for the network environment described in FIG.20. FIG. 21 illustrates how a public or private cloud 764 can be used tohost multiple malicious code detection scanning engines 766, 768, 770and 772 such that the cloud is enabled and configured to allow directremote access to the forensic image 432, 436 of a hard drive to bescanned that is hosted by an Image Host computer 752. The Image Hostcomputer 752 illustrated in FIG. 21 is shown as a local computer system.But those who have skills and experience in various forms ofconnectivity realize that the Image Host 752 could also be located in acloud environment. The Image Host computer system 752, as detailed inFIG. 21, is shown as a local computer system due to security issuesassociated with privacy laws and regulations. The connectivity 776between the cloud 764 and the Image Host 752 is not restricted to anyspecific form of technology as long as the selected technology allowsthe method of the present invention to be made operational in theenvironment described.

The specifications discussed in this application, as well as thepreviously filed provisional application have disclosed preferredembodiments of the present invention and, although specific descriptiveterms are employed, they are used in a generic sense only and not forpurposes of limitation. Obviously, many modifications and variation ofthe present invention are possible once the distinguishingcharacteristics of the present invention are understood. It is thereforeto be understood that the present invention may be implemented otherwisethan as specifically described in this provisional application withoutchanging the focus and advantages derived.

Unless defined otherwise, all technical and scientific terms used hereinhave the same meaning as commonly understood by one of ordinary skill inthe art in the field of this present invention. Although anycompositions, methods, implementations, configurations and means forcommunicating information similar or equivalent to those describedherein can be used to practice this present invention, the preferredcompositions, methods, implementations, configurations and means forcommunicating information are described herein.

Although the present invention has been described in accordance with theembodiments shown, one of ordinary skill in the art will readilyrecognize that there could be variations made to the embodiments withoutdeparting from the scope of the present invention. Accordingly, it isintended that all matter contained in the above application and shown inthe accompanying drawings shall be interpreted as illustrative and not ameans of demonstrating the limits of technology.

What is claimed is:
 1. A multi-engine malicious code scanning method forscanning data sets from a storage device, said method comprising thesteps of: installing a virtual operating system on at least onecomputer, along with a plurality of independent operating systems onsaid computer; for each of said independent operating systems,installing a malware engine, such that said computer includes aplurality of malware engines, each operating separately on itsrespective independent operating system; obtaining at least one data setfrom a storage device; generating a single forensic image of said dataset; applying a recover data application to said data set to generate asingle recovered data set; selecting a plurality of malware engines foranalyzing said single forensic image and said single recovered data set;initiating a scanning of said single forensic image and said singlerecovered data set using said selected plurality of malware engines,wherein each of said malware engines, installed on said indepenentoperating systems of said virtual operating system, may be runconcurrently on said single forensic image and said single recovereddata set; and generating a combined report for each of said malwareengines reporting the results of said scans.